NAVAL  POSTGRADUATE  SCHOOL 
Monterey,  California 


THESIS 


9 


Design  And  Implementation  of  an 
Interface  Editor  for  the 
Amadeus  Multi-Relational  Database 
Front-end  System 

by 

James  Phillip  Hargrove 
March  1993 

Thesis  Advisor:  C.  Thomas  Wu 

Second  Reader:  LCDR  John  A.  Daley,  USN 


Approved  for  public  release;  distribution  is  unlimited. 


93-17445 

iiniiiMiii 


93  8  3  0  01 


DISCLAIMEK  NOTICE 


THIS  DOCUMENT  IS  BEST 
QUALITY  AVAILABLE.  THE  COPY 
FURNISHED  TO  DTIC  CONTAINED 
A  SIGNIFICANT  NUMBER  OF 
PAGES  WHICH  DO  NOT 
REPRODUCE  LEGIBLY. 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  THIS  PAGE 


1 =(  sMlii  fcl  1 1  =1  k WSfcl  I  d  W  V  i  r«1  :  I 


REPORT  DOCUMENTATION  PAGE 


UNCLASSIFIED 


rn  *  UI»hMI  II  *i  a  a  >i  =t-~v< i ;  >i  ^  :  r.i  ,v  :*»]  a w :  i  fi :  i  met* : ;  tc? j ?  I  rj_\  i  w  c 


Computer  Science  Dept. 

Naval  Postgraduate  School 

l 

(if  applicable) 

cs 

Naval  Postgraduate  School 

6c  ADDRESS  (City,  State,  and  ZIP  Code) 

Monterey,  CA  93943-5000 

7b.  ADDRESS  (City,  State,  and  ZIP  Code) 

Monterey,  CA  93943-5000 

8a  NA 

ORGANIZATION 


l  f;'  r«»i  a  a  w  s  I  i 


(if  applicable) 


8c  ADDRESS  (City,  State,  and  ZIP  Code) 


ELEMENT  NO. 


1 1  TITLE  (Include  Security  ClassHication) 

DESIGN  AND  IMPLEMENTATION  OF  AN  INTERFACE  EDITOR  FOR  THE  AMADEUS  MULTI -RELATIONAL  DATABASE 
FRONT-END  SYSTEM  (U) 


ames  Phillip  Hargrove,  USN 


s 


UMMIdl! 


[Tt 


14.  DATE  OF  REPORT  (Year,  Month.  Day) 

930325 


im-/Tcldi{»lllL'H 


e  views  expressed  in  this  thesis  are  those  ol  the  author  and  do  not  rellect  the  ollicial  policy  or 
position  of  the  Department  of  Defense  or  the  United  States  Government. 


COSATI  CODES 


GROUP  SUB-GROUP 


18.  SUBJECT  TERMS  (Continue  on  reverse  H  necessary  and  identity  by  block  number) 
OBJECT-ORIENTED  PROGRAMMING.  USER  INTERFACE  DESIGN.  PROGRAPH, 
VISUAL  PROGRAMMING.  FORM-BASED  INTERFACE,  DATABASE  SYSTEMS 


19.  ABSTRACT  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 

This  thesis  extends  the  Graphical  User  Interface  of  a  prototype  multi-relational  database  front-end  system,  called 
Amadeus.  System  enhancements  are  realized  through  the  application  of  Object-Oriented  Programming  (OOP)  and 
Human-Computer  Interface  (HCI)  design  principles.  Knowledge  gained  from  each  topic  has  been  incorporated  into 
the  design  and  implementation  of  a  Form-based  interface  for  database  data  entry  and  display. 

The  focus  of  this  thesis  is  divided  between  two  issues:  the  development  of  a  set  of  tools  for  creating  and  using  Form 
objects;  and  the  design  of  the  Form  object  itself.  Form  creation  is  accomplished  using  an  application  program  called 
the  Interface  Editor  module.  The  Interface  Editor  is  one  of  six  modules  which,  together,  comprise  the  Amadeus  sys¬ 
tem.  Form  manipulation  occurs  in  a  second  application  which  implements  basic  program  methods  for  controlling  data 
entry  and  display  processes. 

Design  and  implementation  of  this  thesis  was  accomplished  using  the  Prograph  programming  language  and  devel¬ 
opment  environment,  which  provided  a  basic  set  of  system  classes  essential  to  the  implementation  of  the  Form  object 
and  Graphical  User  Interfaces. 


K*1  »]fcft|=||:l*llMC  f/A’/.l  1  *.1-11*1 


I H  Nf.1 :  icl  | :  f.T#ft  3*l>l:lft  AlMC  I 


[g  UNCLASSIFIEDAJNUMITED  Q  SAME  AS  RPT  Q  OTIC  USERS  UNCLASSIFIED 


.  TELEPHONE  (Include  Area  Code) 
18)656-2174 


DD  FORM  1473,  S4  MAR 


83  APR  edition  may  be  used  until  exhausted 
All  other  editions  are  obsolete 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 

UNCLASSIFIED 


Approved  for  public  release;  distribution  is  unlimited 


Author: 


Approved  By: 


Design  and  Implementation  of  an  Interface  Editor  for  the 
Amadeus  Multi-Relational  Database  Front-end  System 


by 

James  Phillip  Hargrove 
Lieutenant  Commander,  United  States  Navy 
BA,  University  of  California,  Berkeley,  1981 


Submitted  in  partial  fulfillment  cf  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  COMPUTER  SCIENCE 


from  the 

NAVAL  POSTGRADUATE  SCHOOL 

March,  1993 


ii 


ABSTRACT 


This  thesis  extends  the  Graphical  User  Interface  of  a  prototype  multi-relational  data¬ 
base  front-end  system,  called  Amadeus.  System  enhancements  are  realized  through  the  ap¬ 
plication  of  Object-Oriented  Programming  (OOP)  and  Human-Computer  Interface  (HCI) 
design  principles.  Knowledge  gained  from  each  topic  has  been  incorporated  into  the  design 
and  implementation  of  a  Form-based  interface  for  database  data  entry  and  display. 

The  focus  of  this  thesis  is  divided  between  two  issues:  the  development  of  a  set  of  tools 
for  creating  and  using  Form  objects;  and  the  design  of  the  Form  object  itself.  Form  creation 
is  accomplished  using  an  application  program  called  the  Interface  Editor  module.  The  In¬ 
terface  Editor  is  one  of  six  modules  which,  together,  comprise  the  Amadeus  system.  Form 
manipulation  occurs  in  a  second  application  which  implements  basic  program  methods  for 
controlling  data  entry  and  display  processes. 

Design  and  implementation  of  this  thesis  was  accomplished  using  the  Prograph  pro¬ 
gramming  language  and  development  environment,  which  provided  a  basic  set  of  system 
classes  essential  to  the  implementation  of  the  Form  object  and  the  Graphical  User  Interfac¬ 
es  developed  for  this  thesis. 
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I.  INTRODUCTION 


This  thesis  investigates  two  separate  topics,  object-oriented  programming  and 
Human-Computer  Interface  (HCI)  design.  Knowledge  gained  from  each  is  applied  to  the 
design  of  a  Form-based  interface  for  database  data  entry  and  display  to  be  used  in 
conjunction  with  a  new  relational  database  query  language  called  Dataflow  Query 
Language  (DFQL).  Central  to  the  Form-based  interface  is  the  design  of  a  Form  object 
which  is  an  abstract  representation  of  a  computer  generated  Form  (and  its  component 
parts).  Forms  of  various  types  are  common  in  everyday  life.  Examples  include  income  tax 
forms,  questionnaires,  job  applications,  invoices  and  order  forms.  Form-based  interfaces 
are  popular  for  database  applications  since  they  extend  the  paper  form  by  creating  a  new 
computer  metaphor  for  these  familiar  objects.  Users  are  thus  able  to  manipulate  form 
images  through  a  Graphical  User  Interface  (GUI)  in  a  similar  manner  as  they  would  a  paper 
form.  This  ability  greatly  assists  user  interaction  with  the  system,  since  users  see  a  display 
of  all  related  fields  and  have  a  feeling  of  control  over  the  data  entry  process 
[Schneiderman92  page  71;  pages  132-133].  Additionally,  few  instructions  are  necessary 
since  the  computer-displayed  form  so  closely  resembles  familiar  paper  forms 
[Schneiderman92  page  132]. 

The  Form-based  interface  discussed  above  actually  consists  of  two  separate 
applications:  The  Interface  Editor  module  and  the  Form  Use  application  program.  The 
Interface  Editor  is  one  of  six  modules  which,  together,  comprise  a  prototype  multi- 

relational  database  front-end  system  called  Amadeus.1  The  purpose  of  the  Interface  Editor 
module  is  to  provide  users  with  a  tool  for  creating  and  editing  custom  data  entry  and  display 
Forms  for  use  by  Amadeus’  Query  Editor  module.  The  Query  Editor  uses  the  DFQL  query 
language  for  database  manipulation,  providing  an  “improved  interface  to  the  relational 

1 .  Amadeus  and  DFQL  will  be  discussed  further  in  Chapter  II. 
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model  of  database  management”  [Clark91  p.  25].  Forms  are  used  in  conjunction  with 
DFQL  queries  to  make  hta  entry  and  display  more  efficient  for  the  system  user. 

The  Interface  Luitor  module  is  a  stand-alone  application  program  which  is  intended  to 
be  used  separately  from  the  Amadeus  database  definition  and  manipulation  modules.  This  f 

seoaiation  results  in  important  advantages: 

1.  First,  a  clear  distinction  between  Form  creation  and  use  is  realized,  simplifying  the  • 

user  interfaces  for  both  the  Interface  Editor  and  other  Amadeus  modules. 

2.  Secondly,  separating  the  Interface  Editor  functions  from  the  remainder  of  the  Amadeus 
modules  keeps  application  size  to  a  minimum  while  supporting  general  object- 
oriented  programming  goals  by  assisting  in  modular  program  development,  testing 
and  debugging. 

The  Form  Use  application  program  is  used  to  validate  the  Interface  Editor’s  Form 
creation  capability,  and  incorporates  control  functions  for  displaying  and  controlling  Form 
objects  used  for  data  entry  and  display.  The  component  parts  of  the  Form  Use  application 
will  ultimately  become  part  the  Amadeus  Query  Editor  module,  which  contains  query 
editing  and  execution  methods  for  the  entire  system.  The  Query  Editor  module  is  currently 
the  topic  of  another  thesis  project,  and  integration  of  the  Form  Use  functions  will  be 
accomplished  as  part  of  that  work. 

All  design  and  programming  for  this  thesis  was  accomplished  using  the  Prograph™2 
programming  language  and  development  environment  Prograph  is  a  visual  language  based 
on  the  dataflow  paradigm.  Since  Prograph  uses  the  Macintosh  ROM-based  toolbox  and 
operating  system  managers,  the  Interface  Editor  and  Form  Use  interfaces  take  on  a 
distinctive  Macintosh  “look  and  feel”. 

Prograph  language  features  relating  to  program  development  and  source  code  listings 
for  this  thesis  are  discussed  in  Chapter  II  and  Appendix  8.  Relevant  Human  Computer 
Interface  design  and  implementation  issues  are  discussed  in  Chapter  III.  The  design  and 

2.  Prograph  is  a  trademark  of  The  Gunakara  Sun  Systems,  Ltd. 
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implementation  of  the  Form  object.  Interface  Editor  and  Form  Use  application  are  detailed 
in  Chapter  IV.  Chapter  V  provides  a  summary  of  this  ♦Sesis,  complete  with  conclusions  and 
recommendations  for  further  research.  Source  code  listings  for  the  Interface  Editor  and 
Form  Use  applications  are  contained  in  Appendix  E. 
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II.  TERMINOLOGY,  BACKGROUND  AND  BASIC  CONCEPTS 


This  chapter  provides  background  information  on  the  Prograph  programming 
language  and  development  environment,  DFQL  and  the  Amadeus  system.  Each  of  these 
concepts  will  be  discussed  briefly.  An  introduction  to  the  Prograph  language  will  then  be 
presented  to  assist  in  the  interpretation  of  code  listings  found  in  Appendix  E.  Finally, 
DFQL  and  Amadeus  will  be  described.  Additional  information  on  these  subjects  may  be 
found  in  Appendices  B  and  C. 


A.  HIGH-LEVEL  PROGRAMMING  LANGUAGES 

One  way  of  classifying  a  programming  language  is  by  the  language’s  level  of 
abstraction.  A  language  is  considered  higher-level  than  another  if  it  can  express  a  program 
with  less  detail  than  the  second  language.  This  means  that  a  high-level  language  enables  a 
programmer  to  concentrate  more  on  what  is  to  be  done  and  less  on  how  to  do  it 
[MacLennar87  p.  485-486].  The  authors  of  Prograph  assert  that  it  is  a  “very  high  level” 
language.  This  implies  that  Prograph  is  about  as  far  removed  from  machine  language  as  is 
practical,  and  is  more  abstract  than  traditional  high-level  programming  languages  such  as 
Ada,  Fortran  or  Pascal. 


B.  VISUAL  PROGRAMMING 

S.  K.  Chang  describes  two  general  categories  of  visual  languages:  those  that  process 
visual  information  and  those  that  make  use  of  visual  expression  (known  as  Visual 
Programming  Languages).  Languages  that  are  used  to  process  visual  information  are 
usually  traditional,  linear  languages  that  have  been  specifically  enhanced  to  handle  visual 
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information  or  objects.  Visual  Programming  Languages,  on  the  other  hand,  deal  with 
objects  which  are  not  normally  expressed  visually,  but  which  are  themselves  visual  in 
nature.  Prograph  is  a  example  of  a  visual,  very  high-level  programming  language. 


C.  OBJECT-ORIENTED  PROGRAMMING 

Object-Oriented  Programming  (OOP)  differs  from  traditional  procedural 
programming  by  the  way  in  which  data  and  action  are  treated.  In  procedural  programming, 
data  and  action  are  treated  separately.  Typically,  data  structures  are  first  defined,  and  then 
a  set  of  procedures  are  developed  to  manipulate  the  data  structures.  With  OOP,  however, 
action  and  data  are  closely  coupled  (i.e.,  data  and  the  actions  associated  with  the  data  are 
defined  together). 

This  section  discusses  the  general  characteristics  of  Object-Oriented  Programming 
Languages  (OOPLs),  and  defines  basic  terms  and  concepts. 

I.  Data  Hiding  (Encapsulation) 

Data  hiding  is  a  process  by  which  data  can  only  be  accessed  by  code  which  is 
specifically  associated  with  the  data.  Data  hiding  is  also  called  encapsulation  because  data 
and  its  associated  code  are  placed  together  in  a  package  or  “capsule”.  Encapsulation  is  an 
important  feature  of  OOP  languages,  and  is  also  incorporated  into  certain  procedural 
languages  such  as  Modula-2  and  Ada.  By  encapsulating  code  and  data,  the  programmer 
guarantees  that  portions  of  a  program  which  do  not  relate  to  specific  data  remain  separate, 
and  cannot  access  that  data. 

Data  hiding  aids  in  modular  program  construction,  since  details  of  the  inner 
workings  of  a  package  are  not  required  by  anything  outside  of  the  package.  When  applied 
properly,  modular  program  design  enables  packages  (modules)  to  be  added,  modified  or 
removed  from  a  program  with  no  impact  on  other  modules.  This  is  generally  not  the  case 
with  procedural  languages  which  do  not  support  encapsulation.  In  such  languages,  making 
a  change  to  one  part  of  a  program  may  impact  other  parts  of  the  program,  producing  a 
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“ripple”  effect  of  program  and  data  dependencies.  Encapsulation  has  been  implemented  in 
the  design  of  both  programs  developed  for  this  thesis.  Portions  of  the  Interface  Editor  have 
been  incorporated  into  the  Form  Use  application,  which  will,  itself,  ultimately  be 
incorporated  into  the  Amadeus  Query  Editor. 

2.  Classes  and  Objects 

An  object  is  an  entity  that  contains  data  and  an  associated  set  of  actions  that 
operate  on  the  data.  Every  object  belongs  to  a  class,  which  defines  the  implementation  of 
a  particular  kind  of  object.  An  individual  object  of  a  class  is  referred  to  as  an  instance  of 
the  class.  Classes  can  be  thought  of  as  templates  for  creating  objects. 

In  object-oriented  programming,  when  a  class  is  created,  attributes  and  methods 
are  defined  for  the  class.  Attributes  are  a  type  of  place  holder  for  a  specific  value.  Objects 
may  have  zero,  one  or  many  attributes.  Methods  represent  known  behaviors  of  instances  of 
a  class,  and  are  roughly  analogous  to  subroutines  in  more  traditional  languages.  [TGS90b 
p.  146,  TGS90c  p.  4,  Symantec91  p.  19-20]  The  objects,  classes  and  methods  developed  as 
part  of  this  thesis  are  discussed  in  Chapter  IV. 

3.  Messages 

In  object-oriented  programming,  objects  communicate  with  other  objects  by 
sending  and  receiving  messages.  Messages  are  analogous  to  sub-routine  calls  in  a 
procedural  programming  language,  and  are  used  to  tell  an  object  to  perform  a  specific 
action. 

4.  Inheritance 

New  classes  can  be  defined  in  terms  of  existing  classes  through  a  process  called 
inheritance.  The  new  class  is  called  a  subclass  or  child,  and  the  existing  class  (from  which 
the  subclass  was  defined)  is  called  a  superclass  or  the  parent  class.  A  subclass  inherits  all 
of  the  attributes  and  methods  of  its  parent  class.  The  parent,  in  turn,  may  have  inherited 
attributes  and  methods  from  its  parent  class.  A  class  inherits  the  combined  attributes  and 
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methods  of  its  ancestors.  However,  a  subclass  does  not  actually  copy  this  information. 
Rather,  it  refers  to  the  information  as  a  parent  class  or  superclass  [Smith91  p.  65]. 

Subclasses  are  normally  created  when  a  new  class  is  needed  which  differs  slightly 
from  an  existing  class.  This  is  possible  because  a  subclass  can  have  its  own  attributes  and 
methods  not  contained  in  the  parent  class.  Prograph  supplies  a  core  of  system-defined 
classes  that  describe  Macintosh  interface  data  structures  such  as  menus,  windows  and 
window  items.  Subclasses  of  these  system  classes  are  developed  by  the  programmer  to 
define  specific  program  actions.  Figure  1  shows  the  Prograph  System  Class  Hierarchy. 


Figure  1:  The  Prograph  System  Class  Hierarchy 
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5.  Polymorphism 

Simply  stated,  polymorphism  allows  the  same  message  to  be  sent  to  objects  of 
different  classes.  Each  object  invokes  a  method  appropriate  for  its  particular  class  [Smith91 
p.  8,  109;  TGS90b,  p.  93].  Using  the  Macintosh  Finder  as  an  example,  the  effect  of  the 
Open  command  depends  on  the  icon  which  has  been  selected.  If  a  folder  icon  is  selected,  a 
folder  is  opened.  If  an  application  icon  is  selected,  the  application  is  opened.  In  effect,  an 
Open  message  is  being  sent  to  various  Finder  objects,  with  each  object  applying  its  own 
Open  method,  as  appropriate.  [Symantec91  p.  22-23] 

D.  DATAFLOW  DIAGRAMS  &  DATAFLOW  PROGRAMMING 

1.  Dataflow  Diagrams 

A  dataflow  diagram  is  a  modeling  tool  that  is  used  extensively  in  operations 
research  and  computer  science  as  an  aid  in  systems  analysis  and  design.  A  dataflow 
diagram  makes  use  of  distinct  graphical  symbols  to  convey  meaning,  is  inherently  visually 
oriented  and  is  closely  related  to  the  directed  graph. 

2.  Dataflow  Programming 

Dataflow  programming  is  a  natural  extension  of  the  dataflow  diagram.  A  dataflow 
program  is  itself  a  dataflow  diagram,  so  this  type  of  programming  allows  the  construction 
of  two-dimensional  graphical  dataflow  models  that  are  directly  translatable  into  computer 
executable  instructions.  Thus,  a  dataflow  program  is,  simultaneously,  a  system  model  and 
an  executable  program. 

Dataflow  programming  does  not  impose  a  specific  ordering  on  program  events. 
Rather,  data  can  be  thought  of  as  actively  flowing  throughout  a  program,  triggering  events 
in  a  non-sequential  manner  as  various  data  dependencies  are  satisfied,  and  corresponding 
program  instructions  are  executed.  This  active  flow  of  data  implies  more  than  one 
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instruction  can  be  evaluated  simultaneously,  making  dataflow  programming  inherently 
concurrent.  |TGS90b] 

E.  PROGRAPH 

Prograph  is  an  object-oriented,  graphic  programming  language  and  development 
environment  that  supports  the  entire  software  design  process.  Prograph  consists  of  the 
following  integrated  components  [TGS90a  p.  1]: 

(1)  pictorial  language, 

(2)  graphic  editor/interpreter  development  environment, 

(3)  Application  Builder  object-oriented  interface  building  toolkit,  and 

(4)  680x0  code  compiler 

Prograph’s  visual  environment  makes  it  different  from  other  programming  languages. 
The  language  syntax  is  entirely  pictorial,  with  text  used  only  for  comments  and  assigning 
names  to  objects,  classes,  methods,  etc.  Code  for  Prograph  applications  are  composed  of  a 
series  of  dataflow  diagrams  consisting  of  operations  (represented  by  icons)  connected  by 
datalinks.  Data  flows  into  an  operation  at  a  terminal  node  located  at  the  top  of  the  operation 
icon,  and  flows  out  of  an  operation  from  a  root  node  located  at  the  bottom  of  the  operation 
icon.  Datalinks  provide  the  paths  along  which  data  flows  into  and  out  of  operations. 
Dataflow  diagrams  in  Prograph  are  displayed  in  case  windows.  Figure  2  shows  a  typical 
case  window. 

Prograph,  as  implemented  on  the  uni-processor  Macintosh,  does  not  support 
concurrency.  Although  the  Macintosh’s  uni-processor  architecture  limits  program 
execution  to  a  single  instruction  at  a  time,  there  is  no  sequential  ordering  placed  on  the 
execution  of  operations  in  a  Prograph  program.  Therefore,  the  overall  character  of  a 
dataflow  program  is  preserved. 
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Figure  2:  Prograph  Case  Window 


1.  Application  Builder 

Prograph  incorporates  an  object-oriented,  graphical  application-interface  toolkit 
(the  Application  Builder)  which  seamlessly  integrates  the  Prograph  development 

environment  with  the  Macintosh  ROM-based  Toolbox1  and  operating  system  managers 
(TGS90a,  TGS90bJ.  Traditional  User  Interface  Management  Systems  or  Interface  Toolkits, 
which  separate  the  user  interface  from  the  application  program,  require  a  complex, 
sequential  edit-link-compile-run  cycle  whenever  changes  are  made  to  an  application. 

1 .  The  Macintosh  Toolbox  is  a  collection  of  low-level  routines  that  implement  the  Macintosh  oper¬ 
ating  system  and  user  interface.  See  also  [Appie85]. 
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However,  since  Prograph’s  Application  Builder  facilities  are  an  extension  of  the  editor  and 
interpreter,  a  dynamic  run-edit-design-run  program  development  cycle  is  employed  which 
significantly  reduces  application  development  time.  Thus,  the  Application  Builder 
provides  a  seamless  integration  between  the  processes  for  developing  user  interfaces  and 
the  classes  and  methods  that  implement  the  fundamental  behavior  of  the  application  itself 
[TGS90b  p.  215-216], 

F.  DATAFLOW  QUERY  LANGUAGE 

The  Dataflow  Query  Language  (DFQL)  is  a  visual,  relational  algebra  which  is  used  to 
manipulate  relational  databases.  Like  Prograph,  DFQL  is  a  dataflow  language,  possessing 
sufficient  expressive  power  and  functionality  to  allow  a  user  to  easily  express  database 
queries.  DFQL  operators  are  constructed  using  three  basic  components:  input  nodes,  a  body 
and  output  nodes.  These  components  correspond  to  the  Prograph  constructs  terminal,  node 
and  root,  respectively,  and  possess  the  same  underlying  principles  and  characteristics  as 
their  Prograph  counterparts.  Figure  3  compares  three  DFQL  primitive  operators  with  their 
equivalent  Structured  Query  Language  (SQL)  queries.  SQL  has  become  the  de  facto 
industry  standard  query  language  for  relational  Database  Management  Systems  (DBMS’). 
However,  SQL  has  problems  with  both  its  design  and  implementation  [Codd88a,  pages  45- 
48,  Codd88b  pages  71-74,  Codd90].  DFQL  was  developed  to  “allow  users  to  achieve  the 
maximum  utility  from  the  relational  model”  by  providing  an  “improved  interface  to  the 
relational  model  of  database  management”  [Clark91  pagel;  page  25]. 

DFQL  operators  can  be  grouped  into  two  basic  categories:  primitive  and  user-defined. 
Primitive  operators  have  a  one-to-one  correspondence  with  methods  in  the  implementation 
language  of  the  interpreter.  User-defined  operators  are  created  from  primitive  operators  and 
possibly  other  user-defined  operators  which  have  been  created  previously.  This  provides  a 
great  deal  of  freedom  and  flexibility  when  constructing  queries,  since  commonly  used 
queries  can  be  combined  into  compact,  user-defined  queries,  eliminating  the  need  to  re- 
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construct  them  each  time  they  are  needed.  Figure  4  shows  a  sample  DFQL  query,  involving 
both  primitive  and  user-defined  operators.  Additional  database  concepts  are  briefly 
discussed  in  Appendix  C. 


Figure  3:  DFQL  Primitive  Operators  and  Their  Corresponding  SQL  Queries 


relation 


condition 


SELECT  DISTINCT  * 
FROM  relation 
WHERE  condition 


SELECT  DISTINCT  * 

FROM  relation  1,  rl,  relation2,  r2 
WHERE  join  condition 


relationl 


relation2 


SELECT  DISTINCT  * 
FROM  relationl 
UNION 

SELECT  DISTINCT  * 
FROM  relation2 
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G.  AMADEUS 

SQL  has  become  the  de  facto  industry  standard  query  language  for  Relational 
Database  Management  Systems.  Although  ANSI  and  ISO  standards  exist  for  SQL,  each 
RDBMS  vendor  normally  supports  its  own  SQL  dialect.  This  presents  a  problem  for  the 
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user  of  a  multiple  back-end2  RDBMS,  since  SQL  queries  for  one  RDBMS  may  not 
necessarily  run  on  a  second  RDBMS.  A  single  front-end  system  that  can  act  as  an  interface 
between  users  and  assorted  back-end  RDBMS  is  required.  Amadeus  is  a  prototype  for  such 
a  system,  which  takes  an  object-oriented  approach  for  federating  relational  databases.  The 
objectives  of  Amadeus  are  [Wu91  pages  8-9]: 

1.  Provide  an  easy  to  use,  yet  powerful  common  language  for  accessing  different  types 
of  RDBMS,  and 

2.  Shield  the  complexity  of  the  underlying  RDBMS. 

Figure  5  compares  the  traditional  DBMS  arrangement  and  Amadeus. 


Figure  5:  Comparison  of  Traditional  DBMS  and  Amadeus 


The  key  features  of  Amadeus  are  its  use  of  the  DFQL  high-level  visual  query  language 
and  an  object-oriented  architecture.  By  using  DFQL  as  the  front-end  query  language,  users 
do  not  have  to  learn  different  dialects  for  each  RDBMS  connected  to  the  system.  Rather, 
DFQL  provides  a  consistent,  easy-to-use  visual  front-end  interface  for  each  back-end 
RDBMS.  Additionally,  the  object-oriented  design  of  Amadeus  ensures  an  easy  to  modify. 


2.  Typically,  a  DBMS  is  separated  into  two  distinct  parts:  the  ‘Yront-end”  or  user  interface,  and  the 
'Track -end”  which  comprises  the  actual  database.  A  multiple  back-end  system  allows  users  to  con¬ 
nect  to  a  number  of  different  DBMS’  from  a  single  front-end. 
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extensible  system,  which  is  demonstrated  by  the  designs  of  both  the  Interface  Editor 
module  and  Form  Use  application.  Amadeus  is  composed  of  a  number  of  modules  which 
can  be  tailored  to  support  individual  user  requirements.  The  six  modules  include: 

1.  Database  Engine 

This  module  performs  all  database  operations  by  either  carrying  out  the 
operations  internally  (by  using  the  kernel  database  engine)  or  by  delegating  the  operations 
to  a  back-end  RDBMS.  In  the  latter  case,  generated  SQL  statements  are  passed  to  the  back¬ 
end  for  processing.  Each  supported  RDBMS  has  its  own  corresponding  Amadeus  database 
engine  module  (e.g.,  Oracle  database  engine,  Ingres  database  engine,  DB2  database  engine, 
etc). 

2.  Interface  Editor 

The  Interface  Editor  module  is  used  to  design  input  forms,  output  screen  displays 
and  hardcopy  reports.  The  Interface  Editor  allows  or  disallows  certain  types  of  control 
objects  according  to  the  types  supported  by  the  connected  RDBMS.  The  design  and 
implementation  of  the  Interface  Editor  module  comprises  a  major  portion  of  this  thesis. 

3.  Database  Editor 

The  Database  Editor  module  is  used  to  define  and  modify  databases.  This  module 
adjusts  itself  to  allow  different  access  controls  to  each  database,  depending  on  the 
connected  back-end  RDBMS. 

4.  Relation  Editor 

The  Relation  Editor  module  is  used  for  defining  and  modifying  relations.  The 
module  allows  users  to  define  relations  according  to  the  rules  of  the  connected  back-end 
RDBMS. 

5.  Query  Editor 

The  Query  Editor  module  is  used  to  perform  ail  aspects  of  database  operations. 
The  module  allows  identical  DFQL  diagrams  to  be  used  for  querying  different  connected 
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back-end  RDBMS.  Since  each  RDBMS  employs  its  own  dialect  of  SQL,  the  Query  Editor 
gener  ,tes  appropriate  SQL  statements  tailored  to  the  connected  RDBMS.  All  of  this  is 
transparent  to  the  user  who  is  formulating  the  query.  Forms  created  by  the  Interface  Editor 
module  are  used  by  the  Query  Editor  to  support  data  input  and  output  (display).  Objects 
required  for  data  input,  display  and  type  checking  have  been  developed  and  implemented 
as  part  of  this  thesis,  and  will  ultimately  be  integrated  into  the  Query  Editor. 

6.  Program  Editor 

The  Program  Editor  module  is  used  for  creating  database  application  programs. 
The  module  is  not  yet  implemented. 
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III.  HUMAN-COMPUTER  INTERFACE  DESIGN  ISSUES 


A.  INTRODUCTION 

This  chapter  provides  a  brief  discussion  of  Human-Computer  Interface  (HCI)  design 
issues  relevant  to  the  design  and  implementation  of  the  Interface  Editor  module  and  Form 
Use  application  program.  Additional  HCI  issues  are  discussed  in  Appendix  D. 

Human-Computer  Interface  (HCI)  design  is  a  constantly  evolving,  multi-disciplinary 
field  of  study  that  focuses  on  computer  systems  and  the  way  in  which  people  interact  with 
them.  Contributions  from  the  fields  of  computer  science,  human  factors,  psychology, 
graphic  arts  and  education,  play  an  essential  role  in  the  HCI  design  process.  The  field  is 

relatively  new1,  and  is  being  influenced  “by  the  tide  of  development  -  by  the  persistent 
flood  of  hardware  and  software  products  in  the  marketplace,  and  by  the  changing  nature  of 
how  they  are  created,  purchased  and  put  into  use.”  [Winograd90,  p.  443] 

1.  A  Brief  History 

Grudin  identifies  evolutionary  stages  of  user  interfaces  by  describing  the 
following  five  levels  of  user  interface  focus.  These  levels  correspond  to  general 
characteristics  of  user  interfaces  at  various  evolutionary  stages,  from  the  1950’s  (level  one) 
into  the  future  (stages  four  and  five)  [Grudin90  p.  261-265]: 

1.  The  interface  as  hardware. 

2.  The  interface  as  software 

3.  The  interface  as  terminal. 

4.  The  interface  as  dialogue. 

5.  The  interface  as  work  setting. 


1.  The  Association  of  Computing  Machinery  (ACM)  held  its  first  conference  on  Computer  and  Human 
Interaction  (CHI)  in  1981 .  The  ACM  special  interest  group  on  Computer-Human  Interaction  (SIGCHI)  was 
founded  shortly  thereafter,  and  held  its  first  annual  conference  in  1983. 
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The  first  user  interfaces  were  developed  in  the  1950’s,  and  were  tied  directly  to 
computer  hardware.  This  did  not  present  a  problem,  since  engineers  were  the  primary  users 
of  computers  and  were  quite  comfortable  working  at  the  machine-level.  In  the  1960’s  and 
1970’s,  user  interfaces  began  taking  on  forms  which  better  assisted  computer  programmers. 
These  new  interfaces  included  high-level  programming  languages,  operating  systems, 
compilers,  debuggers  and  assemblers.  During  this  period  (level  two),  the  standard  teletype 
was  the  preferred  means  of  communicating  with  a  computer.  Bit-mapped  graphics  and 
cathode-ray  tubes  (CRTs)  gradually  replaced  the  more  primitive  interface  devices,  but  for 
the  most  part,  the  governing  concept  of  the  time  remained  “the  ‘friendliest’  user  interface 
was  the  briefest  user  interface”  [Ambler89  p.  19]. 

The  proliferation  of  the  personal  computer  in  the  mid-1980’s  saw  the  emergence 
of  new  computer  markets  aimed  at  the  non-pregrammer.  This  was  accompanied  by  a  shift 
of  focus  in  user  interfaces  towards  visual  displays  and  interactive  computing  systems  (level 
three).  This  focus  is  intact  today;  is  dominated  by  research  into  basic  perceptual  and 
cognitive  processing  issues  [Grudin90  p.  264],  and  influences  the  design  of  the  interfaces 
developed  for  this  thesis. 

The  last  two  levels  of  user  interface  focus  (levels  four  and  five)  involve  more 
abstract  concepts  and  relationships.  At  these  levels  interface  actors,  agents,  dialogs  and 
Virtual  Reality/ Virtual  Environments  enter  into  the  realm  of  user  interface  design. 
Specifically,  level  four  involves  a  higher  level  cognitive  focus  and  attempts  to  model  end- 
user  goals  and  plans,  develop  a  sense  of  dialogue  with  the  user,  and  create  adaptive  user 
interfaces.  Level  Five  is  directed  towards  the  work  se  -ng.  w  here  computers  are  expected 
to  play  an  important  role  in  supporting  group  working  environments.  Examples  of  such 
“groupware”  systems  include  electronic  mail,  co-authorship,  distributed  project 
management  and  group  decision  support.  [Grudin90  p.  264-265] 

The  five  levels  of  interface  focus  are  summarized  in  the  following  table 
[Grudin90  p.  265]: 
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Table  I:  SUMMARY  OF  THE  DISTINCTIONS  ACROSS  LEVELS  OF  INTERFACE  FOCUS 


Level  1 
Interface  as 
hardware 

Level  2 
Interface  as 
software 

Level  3 
Interface  as 
terminal 

Level  4 
Interface  as 
dialogue 

Levels 
Interface  as 
work  setting 

Principal 

users 

Engineers/ 

programmers 

Programmers 

End  users 

End  users 

Groups  of 

End  users 

Interface 

specialist 

disciplines 

Electrical 

engineering 

Compute’ 

science 

Human  factors 

cognitive 

psych 

graphic  design 

Cognitive 
psychology, 
cognitive 
science,  (dra¬ 
matic  arts?) 

Social  psych., 
anthropology, 
organizational, 
etc. 

Research 

Methods 

Largely  infor¬ 
mal 

Largely  infor¬ 
mal 

Laboratory 

experiment 

Wizard  of  Oz, 
thinking 
aloud,  data 
capture 

Ethnographic, 

contextual. 

participant 

observer 

Duration  of 
basic  events 
studied 

Microseconds/ 

hours 

Milliseconds/ 

hours 

Seconds 

Minutes 

Days 

Cost  of 
evaluation 

Lowest 

Low 

Moderate 

High 

Highest 

Precision, 

generality 

Highest 

High 

Moderate 

Low 

Lowest 

Major  focus 

1950’s 

1960’s- 1970’s 

1970’s-1990’s 

1980’s- 

1990’s- 

B.  TYPES  OF  USER  INTERFACES 

I.  Command  Languages  and  the  Command  Line  Interface 

Command  languages  originated  with  operating  system  commands,  and  can  be 
distinguished  by  their  immediacy  and  by  their  impact  on  devices  or  information 
[Schneiderman92  p  144].  Commands  are  generally  brief,  transitory  and  produce  an 
immediate  result  on  some  object  of  interest.  Command  languages  can  be  extended 
somewhat  through  the  use  of  macros  which  allow  constructing  reusable  sequences  of 
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commands.  Command  languages  may  consist  of  single  commands  or  have  complex  syntax. 
Operations  may  number  into  the  thousands. 

The  command-line  interface  was  the  dominant  form  of  user  interface  until  the 
early-1980’s.  Despite  its  recognized  problems  (including  the  potential  for  increasing 
cognitive  load  by  requiring  a  user  to  memorize  a  potentially  large  set  of  (not  necessarily 
logical)  commands,  flags,  formats  and  associated  syntax)  the  command-line  interface 
survives  today  in  many  popular  systems2.  One  reason  for  this  is  simplicity.  The  command¬ 
line  interface  is  not  as  dependent  upon  high-speed  computer  architecture  as  are  Graphical 
User  Interfaces  (GUI).  Additionally,  command-line  interfaces  are  relatively  easy  to 
program.  However,  this  does  not  necessarily  translate  into  an  intuitive,  easy  to  use 
interface,  as  evidenced  by  the  following  Unix  command  which  blanks  lines  from  a  file: 

GREP  -V  A$FILEA  >  FILEB 

Schneiderman  provides  the  following  summary  of  command  languages  in 
[Schneiderman92  pp.  174-175]: 

Command  languages  can  be  attractive  when  frequent  use  of  a  system  is  anticipated, 
users  are  knowledgeable  about  the  task  domain  and  computer  concepts,  screen  space  is 
at  a  premium,  response  time  and  display  rates  are  slow,  and  numerous  functions  that 
can  be  combined  in  many  ways  are  supported.  Users  have  10  learn  the  semantics  and 
syntax,  but  they  can  initiate  rather  than  respond,  rapidly  specifying  actions  involving 
several  objects  and  options. 

While  command  languages  are  appropriate  for  certain  types  of  interfaces,  they  are 
inappropriate  for  the  implementation  of  the  Interface  Editor  module  and  Form  Use 
application.  The  desired  interface  must  be  able  to  represent  real-world  objects  (Forms)  in 
a  graphical  environment,  and  allow  manipulation  of  these  objects  in  much  the  same  way  as 
a  real-world  Form  object  is  manipulated.  This  requires  a  Graphical  User  Interface. 


2.  MS-DOS  and  Unix  are  examples  of  command-line  based  interfaces  which  still  enjoy  wide  popularity 
today. 
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2.  Graphical  User  Interfaces 

In  the  command-line  interface,  the  user  was  restricted  to  working  only  with 
textual  information.  The  evolution  of  hardware  (and  accompanying  software)  technology 
enabled  researchers  to  move  beyond  the  confines  of  the  text-based  interface  by  translating 
familiar  every-day  objects  into  the  Human-Computer  Interface.  For  the  first  time,  users 
could  manipulate  information  on  a  computer  monitor  in  much  the  same  way  as  they  did  in 
the  real-world.  The  computer  screen  became  a  metaphor  for  a  desktop  which  contained 
windows,  icons,  menus  and  other  graphical  objects.  The  concept  of  What-You-See-Is- 
What-You-Get  (WYSIWYG)  was  introduced  in  word-processing,  so  that  the 
representation  of  a  page  on  a  computer  screen  was  identical,  in  nearly  every  respect,  to  the 
printed  output.  Multiple  windows  could  be  overlaid  onto  the  desktop.  Each  window  could 
be  a  terminal  (or  shell)  on  the  computer,  a  terminal  onto  another  machine,  or  the  interface 
to  a  software  application  (such  as  word -processing/desktop  publishing,  database, 
spreadsheet,  or  graphics  design  packages).  [Schneiderman92  page  198;  Locke  page  1 1] 

There  are  two  major  consequences  (from  a  user’s  perspective)  of  the  graphical 
user  interface.  The  first  is  that  the  user  is  more  isolated  from  the  operating  system,  and  is 
better  able  to  concentrate  directly  on  performing  a  task  rather  than  having  to  interact  with 
the  operating  system  in  order  to  perform  the  task.  For  example,  to  open  a  file  in  a  graphical 
interface  a  user  might  select  the  document  by  clicking  on  its  icon  with  a  mouse  key.  The 
underlying  operating  system  commands  for  opening  the  document  are  invoked  by  the 
interface.  In  a  command-line  interface,  operating  system  commands  to  open  the  document 
are  invoked  explicitly  by  the  user. 

Secondly,  the  graphical  interface  lead  to  the  concept  of  consistency,  whereby 
certain  properties  of  an  application  program’s  user  interface  possess  predictable 
characteristics  and  behaviors.  Thus,  a  consistent  interface  is  one  in  which  specific 
commands  always  result  in  the  same  action(s)  and  produce  the  same  results).  The  Interface 
Editor  module  presents  a  consistent  interface  for  designing  and  editing  Form  objects. 
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3.  Direct  Manipulation 


Direct  manipulation  refers  to  a  type  of  graphical  user  interface  in  which  the  user 
operates  on  a  representation  of  the  objects(s)  of  interest  [Schneiderman92  p.  33].  Typically, 
some  type  of  a  pointing  device  (such  as  a  mouse,  track-ball  or  pen  and  tablet)  are  employed 
to  permit  user  interaction  with  objects  which  appear  on  the  computer  screen.  The  Interface 
Editor  module  employs  a  direct  manipulation  interface,  which  is  discussed  in  Chapter  VI. 


C  EVALUATION  AND  USEABILITY  OF  USER  INTERFACES 

This  section  presents  evaluation  guidelines  and  usability  parameters  which  have  been 
incorporated  into  the  design  of  the  Interface  Editor  module  and  Form  Use  application. 
Usability  parameters  tend  to  reflect  a  user’s  attitude  towards  a  specific  interface,  while 
evaluation  guidelines  outline  key  principles  for  good  HCI  design. 

1.  Evaluation 

Jakob  Nielsen  proposes  the  following  four  methods  for  evaluating  a  user  interface 
[Nielsen90a]:  formally,  automatically,  empirically  and  heuristically.  Of  these  methods,  the 
heuristic  method  has  been  applied  to  the  design  of  the  interfaces  developed  for  this  thesis. 

Heuristic  evaluation  essentially  entails  looking  at  an  interface  and  deciding  what 
is  good  and  what  is  bad  about  it.  To  be  consistent  the  evaluation  should  be  based  on  a  set 
of  established  guidelines  which,  in  practice,  can  easily  number  in  the  hundreds  or 
thousands.  This  is  especially  true  if  the  guidelines  define  a  specific  interface  standard.  In 
order  to  make  the  heuristic  evaluation  process  more  manageable,  Nielsen  and  Molich 
propose  using  the  following  set  of  heuristics  which  were  chosen  for  their  ability  to  explain 
a  large  proportion  of  the  problems  encountered  in  interface  designs  [Nielsen90a]. 

1.  Simple  and  natural  dialogue 

2.  Speak  the  user’s  language 

3.  Minimize  user  memory  load3 

4.  Be  consistent 
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5.  Provide  feedback 

6.  Provide  clearly  marked  exits 

7.  Provide  shortcuts 

8.  Good  error  messages 

9.  Prevent  errors 

2.  Usability 

Nielsen  discusses  five  generally  accepted  usability  parameters  for  computer 
systems  while  applying  them  specifically  to  hypertext4  systems.  [Nielsen  90b]  These  five 
parameters  are: 

1.  Easy  to  learn.  A  new  user  can  quickly  get  some  work  done  with  the  system. 

2.  Efficient  to  use.  Once  a  user  becomes  familiar  with  the  system,  a  high  level  of 
productivity  is  possible. 

3.  Easy  to  remember.  After  an  absence  from  the  system,  the  average  user  can  quickly 
get  back  “up  to  speed”  on  the  system  with  little  effort  or  re-training  required. 

4.  Few  errors.  Use  of  the  system  does  not  in  itself  promote  errors.  A  user  can  easily 
recover  from  an  error  if/when  one  occurs  and  the  system  must  be  immune  to 
catastrophic  errors. 

5.  Pleasant  to  use.  Users  like  using  the  system  (or,  possibly  more  common,  users  do  not 
dread  using  the  system). 

D.  DIALOG  DESIGN 

Dialog  is  essential  to  the  successful  interface  design  for  interactive  systems.  Dialog 
encompasses  everything  related  to  a  user’s  interaction  with  a  system,  including  user  input 


3.  Studies  of  human  information  processing  indicate  that  human  channel  capacity  or  processing  power 

'  is  limited  to  roughly  2.5  bits  of  information,  which  translates  to  about  seven  (plus  or  minus  two)  items. 

4.  Hypertext  refers  to  a  text  system  consisting  of  non  sequential  text  nodes  and  connecting  links. 
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and  command  selection,  system  feedback  (such  as  alert,  error  and  status  messages)  and 
system  error  handling. 

1.  Dialog  Design  Rules 

Schneiderman  provides  the  following  Eight  Golden  Rules  of  Dialog  Design: 
[Schneiderman92  pages  72-74]  which  have  been  incorporated,  to  varying  degrees,  into  the 
design  of  the  user  interface  developed  for  this  thesis. 

1.  Strive  for  consistency.  Consistent  sequences  of  actions  should  be  required  in  similar 
situations;  identical  terminology  should  be  used  in  prompts,  menus  and  help  screens; 
consistent  commands  should  be  employed  throughout  The  interface  which  controls 
Form  design  and  editing  in  the  Interface  Editor  module  are  essentially  identical, 
presenting  a  consistent  interface.  Help  windows  are  identical,  although  the  topics  for 
each  window  differ  depending  on  the  window  (Design  Form,  Edit  Form,  Tab  Order, 
Form  View)  which  the  user  is  currently  working  in. 

2.  Enable  frequent  users  to  use  shortcuts.  This  is  supported  in  the  Interface  editor  by 
the  inclusion  of  command  keys  and  an  icon  bar  (discussed  in  chapter  IV). 

3.  Offer  informative  feedback.  For  every  operator  action,  there  should  be  some  system 
feedback.  Each  action  in  the  Interface  Editor  and  Form  Use  applications  provides 
some  form  of  user  feedback.  Icon  Buttons  invert  when  selected,  dialogs  sound  an  alert 
when  activated,  the  name  of  the  active  Form  (in  the  Form  View  window)  changes  as 
a  Form  is  opened  or  closed. 

4.  Design  dialogs  to  yield  closure.  Sequences  of  actions  should  be  organized  into  groups 
with  a  beginning,  middle,  and  end.  This  principle  is  incorporated  into  the  command 
sequence  required  to  design  and  edit  a  Form  object. 

5.  Offer  simple  error  handling.  Design  the  system  so  the  user  can’t  make  a  serious 
error.  The  system  should  be  able  to  detect  errors  and  offer  simple,  comprehensible 
mechanisms  for  handling  the  error. 


6.  Permit  easy  reversal  of  actions.  As  much  as  possible,  actions  should  be  reversible. 
This  is  the  most  difficult  rule  to  implement.  Reversal  of  actions  is  permitted  only  to  a 
limited  extent  in  the  Interface  Editor  module.  Users  have  the  option  of  saving  or 
discarding  (without  saving)  Forms  from  the  Design  Form  window.  While  editing  a 
Form,  changes  can  be  discarded  without  saving  (essentially  reversing  a  sequence  of 
editing  commands).  Certain  actions,  such  as  deleting  a  Form  from  disk,  can  not  be 
reversed. 

7.  Support  internal  locus  of  control.  Users  want  to  feel  in  control.  Surprising  system 
actions,  tedious  sequences  of  data  entries,  incapacity  or  difficulty  in  obtaining 
necessary  information,  and  the  inability  to  produce  the  action  desired  all  build  anxiety 
and  dissatisfaction. 

8.  Reduce  short-term  memory  load  Keep  displays  simple.  Offer  on-line  help  and 
assistance  to  the  user.  A  simple  on-line  help  system  has  been  implemented  in  the 
Interface  Editor  and  Form  Use  applications.  Additionally,  program  control  features 
have  been  kept  to  a  minimum  without  sacrificing  the  power  and  flexibility  of  the 
interface. 

2.  User  Feedback 

System  feedback  should  be  concise,  descriptive  and  informative.  A  user  should 
not  have  to  question  the  meaning  of  a  system-generated  error  or  status  message.  Interfaces 
which  isolate  a  user  from  the  underlying  operating  system  (such  as  the  Macintosh  Finder) 
have  the  potential  to  confuse  a  user  with  poorly  phrased  dialogs  which  assume  (or  require) 
intimate  knowledge  of  the  operating  system.  The  user  feedback  features  of  the  Interface 
Editor  and  Form  Use  applications  have  been  designed  to  avoid  this  type  of  problem.  In 
addition  to  the  eight  rules  of  dialog  design  listed  in  the  last  section,  system  feedback  to  the 
user  (including  alerts,  dialogs,  prompts  and  error  messages)  for  these  two  interfaces  also 
includes  the  following  guidelines  [Apple85]: 
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1.  Use  plain  language. 

2.  Use  an  active  voice. 

3.  Phrase  messages  so  that  they  are  unambiguous. 

4.  Use  icons  whenever  possible.  Graphics  can  describe  some  errors  better  than  words, 
and  familiar  icons  can  help  users  better  distinguish  their  alternatives. 

5.  Dialogs  should  be  informative,  widii.6  enough  information  to  enable  the  user  to  take 
the  appropriate  action. 

6.  Never  refer  the  user  to  external  documentation  for  further  clarification. 
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IV.  DESIGN  AND  IMPLEMENTATION 


A.  DEVELOPMENT  PROCESS 

The  Prograph  programming  environment  lends  itself  extremely  well  to  both  structured 
and  evolutionary  development  processes  [TGS90b,  pages  230-231].  Structured 
development  is  normally  associated  with  a  “top-down”  design  strategy  employing  a 
structured,  analytic  approach  to  system  design.  Program  code  is  not  written  until  the  project 
has  been  completely  specified.  All  documentation  associated  with  the  system  (e.g., 
requirements,  design  and  test  documents  as  well  as  the  actual  program  code),  is  rigorously 
maintained.  Any  changes  to  the  system  are  implemented  in  a  manner  similar  to  the  original 
design  effort,  and  can  be  considered  a  mini-development  process. 

Evolutionary  development,  on  the  other  hand,  is  usually  associated  with  creative 
prototyping  styles  such  as  those  found  in  research  settings  where  the  goal  is  to  explore  new 
ideas  without  being  bound  by  rigid  documentation  and  specification  rules.  Thus,  changes 
can  be  made  quickly  and  easily. 

Prograph’s  seamless  editor/interpreter  environment  provides  the  tools  necessary  to 
create  and  edit  applications  “on  the  fly”,  easily  accommodating  the  evolutionary  approach 
to  systems  development.  For  this  reason,  and  the  fact  that  interface  design  in  general 
requires  a  great  deal  of  flexibility  while  trying  out  new  ideas,  an  evolutionary  design 
approach  was  chosen  for  this  thesis.  The  visual  nature  of  Prograph  makes  an  application 
both  a  system  model  and  an  executable  program.  In  this  respect,  the  application  code 
provides  up-to-date  dataflow  diagrams  of  the  Interface  Editor  module  at  each  stage  of 
development. 
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B.  USER  INTERFACE  CONSIDERATIONS 


Two  user  interfaces  were  developed  for  this  thesis:  the  Interface  Editor  module 
interface  and  the  Form  Use  application  program  interface.  A  central  feature  of  the  Interface 
Editor’s  user  interface  is  the  incorporation  of  the  following  four  separate  methods  for 
controlling  program  action: 

1.  A  menu  bar  (with  associated  pull-down  menu  commands). 

2.  Window  Buttons. 

3.  Command-key  equivalents  to  menu  commands. 

4.  An  Icon  Bar. 

The  first  three  methods  are  included  to  conform  to  existing  Macintosh  user  interface 
guidelines.  Most  casual  users  of  graphical  user  interfaces  are  familiar  with  button  objects 
and  the  menu  bar,  while  more  experienced  users  are  generally  comfortable  with  command 
key  equivalents  for  menu  bar  items.  The  fourth  method  is  the  icon  bar,  which  is  located  at 
the  top  right-hand  comer  of  the  Interface  Editor’s  main  window.  The  decision  to  include  an 
icon  bar  was  based  on  a  desire  to  extend  the  traditional  Macintosh  interface,  provide  an 
alternative  means  of  program  control  for  the  user  and  to  explore  icon  development  issues 
in  general.  Icon  buttons  are  also  included  as  the  control  mechanism  for  the  data  input  and 
display  windows  developed  for  the  Form  Use  application,  and  provide  a  consistent  control 
interface  for  all  Amadeus-related  Form  manipulation  actions. 

Icon  design  presents  a  number  of  difficulties,  chief  among  them  the  fact  that  what  may 
be  clear  to  one  person  may  be  completely  obscure  to  another.  Alan  Kay  describes  this 
problem  as  a  consequence  of  semantic  focus,  having  to  do  with  the  amount  of  meaning  and 
connectivity  that  can  be  solved  by  looking  at  a  diagram  (Kay  in  Laurel91,  p.  202]. 

Poorly-designed  icons  do  not  readily  suggest  the  underlying  metaphor  or  associated 
program  action.  In  such  cases,  a  user  is  forced  to  learn  what  the  icon  actually  does  rather 
than  what  it  suggests.  This  can  be  a  difficult  undertaking  given  an  interface  with  dozens  of 
icon:-,  a  popular  practice  in  a  growing  number  of  commercial  software  products  today. 
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C.  THE  INTERFACE  EDITOR 


1.  Program  Control  Decisions 

Menu  bar  commands  (and  their  command-key  equivalents)  remain  hidden  from 
view  until  the  appropriate  menu  item  is  selected,  at  which  time  its  associated  menu  items 
become  visible.  The  icon  bar,  however,  remains  visible  whenever  the  main  module  window 
is  active.  Users  are  generally  more  comfortable  in  an  environment  where  objects  are 
brought  to  them  instead  of  having  to  search  for  the  objects.  This  is  referred  to  as  user- 
centered  design  (Tognazzini91  p.  172].  The  inclusion  of  ilie  icon  bar  satisfies  this  user- 
centered  design  criteria,  eliminating  the  requirement  for  a  user  to  constantly  search  pull¬ 
down  menus  or  remember  command-key  combinations  to  select  specific  program  control 
actions. 

Commands  relating  to  Form  management  (New,  Open,  Close,  Save,  Save  As, 
Print)  are  found  in  both  the  icon  bar  and  the  Forms  menu  bar  menu.  Similar  commands 
are  found  in  other  Amadeus  modules  in  a  Database  menu  (for  database  management).  The 
Forms  and  Database  menu  contents  are  similar  to  the  File  menu  commands  found  in  the 
Macintosh  Finder.  This  presents  a  consistent  interface  across  the  Amadeus  application  and 
Finder.  Thus,  there  should  be  no  confusion,  for  example,  as  to  the  meaning  of  the  Open 
command  (which  opens  a  Form  in  the  Interface  Editor  Module,  a  Database  in  the  Amadeus 
database  definition  module,  and  a  File  in  the  Macintosh  Finder).  This  is  also  consistent  with 
general  object-oriented  programming  concepts,  since  a  single  command  (message),  in  this 
case  Open,  results  in  different  actions  depending  on  the  receiving  object  (Forms  menu. 
Database  menu  or  File  menu). 

Not  all  Interface  Editor  icon  bar  commands  are  available  as  menu  bar  selections. 
Commands  without  parallels  in  Amadeus’  Database  and  the  Macintosh  Finder’s  File 
menus  are  found  only  in  the  icon  bar,  and  include  Edit  Form,  Delete  Form,  Help  and  user 
Preferences  controls.  The  decision  not  to  include  these  commands  in  the  Forms  menu 
contributes  to  the  overall  consistency  of  the  user  interface. 
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2.  Icon  Design 

Icons  included  in  the  Interface  Editor  present  images  commonly  found  on  the 
Macintosh  desktop.  Where  no  desktop  correlations  could  be  found,  text  was  incorporated 
as  much  as  possible  in  an  icon’s  graphic  design.  The  intent  of  including  icons  in  the  user 
interface  was  not  to  introduce  a  completely  new  set  of  metaphors,  but  to  build  on  what  a 
user  is  (theoretically)  already  familiar  with.  The  choice  of  individual  icons  was  made  after 
examining  commercial  software  products  which  employ  icons  for  program  control  and  a 
survey  of  literature  on  icon  design.  The  icon  buttons  themselves  were  given  color  and  three- 
dimensional  shading  to  make  them  stand  out  against  the  rest  of  the  interface.  Muted  colors 
were  chosen  to  avoid  overpowering  the  user’s  senses. 

It  is  not  reasonable  to  assume  that  every  user  will  correctly  identify  the  purpose 
of  each  icon  the  first  time  the  interface  is  used.  For  this  reason,  consideration  was  given  to 
including  text  labels  undereach  icon  button  identifying  its  function  (e.g.,  “open”  beneath 
the  open  icon  button).  However,  this  tended  to  clutter  the  icon  bar  and  required  the  use  of 
very  small  text  which  proved  difficult  to  read.  Ultimately  a  decision  was  made  not  to 
include  identifying  text  for  each  icon  button.  To  compensate  for  the  lack  of  amplifying  text, 
the  Macintosh  System  7  Balloon  Help  feature  (which  is  supported  by  Prograph  version  2.5) 
is  used  to  provide  a  brief  synopsis  of  each  interface  object  (buttons,  icons,  menus,  menu 
items  and  other  window  items). 

Space  has  been  left  in  the  icon  bar  to  accommodate  additional  icon  buttons  should 
the  need  arise.  ResEdit1  and  Prograph’s  Icon  Button  class  (discussed  later  in  this  section) 
provide  a  straightforward  means  of  adding  icon  buttons  to  the  interface,  or  modifying 
existing  icons,  as  required. 


1.  ResEdit  is  a  resource  editor  utility  available  from  Apple  Computer,  Inc.  which  allows  editing,  cre¬ 
ation  and  deletion  of  a  Macintosh  application  program’s  resource  data. 
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3.  End-User  Views 


The  Interface  Editor  module’s  design  assumes  two  general  types  of  users: 
database  administrators  (who  create  databases  and  data  entry/display  Forms)  and  data 
entry/retrieval  personnel  (who  use  the  Forms).  This  distinction  led  to  a  decision  to 
implement  the  Interface  Editor  as  a  separate  application  rather  than  integrate  it  into  the 
Query  Editor.  One  consequence  of  this  decision  was  the  loss  of  a  straight-forward 
connection  to  the  database  definition  of  the  active  database.  The  solution  to  this  problem 
was  the  creation  of  an  external  database  definition  disk  file  to  substitute  for  the  ability  to 
read  information  directly  from  an  active  database’s  class  attributes.  However,  the  decision 
lead  to  a  more  manageable  and  maintainable  system,  due  to  the  smaller  program  size  and 
accompanying  modular  design. 

4.  Class  Descriptions 

This  section  describes  classes  unique  to  the  Interface  Editor  module.  Prograph 
System  Classes  will  not  be  discussed.  Figure  1  shows  the  Interface  Editor  module  class 
hierarchy. 


Figure  1:  The  Interface  Editor  Module  Class  Hierarchy 
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a.  IE  Window 


This  class  controls  the  user’s  view  of  the  Interface  Editor  module.  The  main 
module  window  is  an  instance  of  this  class.  All  menu,  button  and  icon  bar  selections  from 
the  main  window  are  handled  by  methods  defined  in  this  class. 

b.  Help 

Help  windows  are  defined  for  the  following  Interface  Editor  windows: 
Interface  Editor  Window,  Define  Form,  Edit  Form.  All  help  windows  are  instances  of  this 
class. 


c.  Tab  Order 

This  class  allows  the  user  to  define  the  tab  order  of  a  Form.  The  tab  order  of 
a  Form  is  determined  by  the  order  in  which  a  field  appears  in  a  Form’s  field  list.  Altering 
the  order  of  a  field  in  this  list  changes  the  tab  order  of  the  Form.  The  tab  order  window  is 
an  instance  of  this  class. 

<L  Preferences 

This  class  allows  the  user  to  change  the  foreground  and  background  colors  of 
a  Form.  Supported  colors  include:  black,  white,  red,  green,  blue,  cyan,  magenta  and  yellow. 
The  User  Preferences  window  is  an  instance  of  this  class. 

e.  Design  Form 

This  class  allows  the  user  to  define  new  input  Forms.  The  Design  Form 
window  is  an  instance  of  this  class. 

f.  Edit  Form 

This  class  allows  the  user  to  edit  the  Form  which  is  displayed  in  the  Interface 
Editor’s  main  window  (the  currently  active  Form).  The  Edit  Form  window  is  an  instance 
of  this  class.  The  Edit  Form  Class  is  a  descendant  of  Design  Form,  and  inherits  its  methods. 
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g.  Credits 

Each  Macintosh  application  program  has  an  About  menu  item  in  its  Apple 
Menu.  Selecting  this  item  displays  general  information  about  the  application.  The  About 
window  is  an  instance  of  the  Credits  class,  and  displays  programmer  credits. 

h.  Display  Info 

This  class  controls  display  of  field  information.  Double-clicking  on  a  field  of 
the  active  Form  in  the  Form  View  window  opens  a  window  which  lists  the  characteristics 
(attributes  and  attribute  values)  of  the  particular  field.  The  Display  Info  window  is  an 
instance  of  this  class. 

L  Dialog 

The  Dialog  class  contains  the  methods  for  displaying  dialog  boxes  in 
response  to  user  actions. 

j.  OK  Dialog 

This  class  provides  the  window  definition  for  a  dialog  which  contains  only 
one  user  choice  (OK),  which  is  used  to  alert  the  user  to  a  specific  program  condition. 

k.  YesINo  Dialog 

This  class  provides  the  window  definition  for  a  dialog  which  contains  two 
user  choices  (YES  and  NO),  and  is  used  to  obtain  user  confirmation  before  a  specific 
program  action  is  executed. 

5.  User  Interface 

This  section  describes  the  user  interface  for  the  Interface  Editor  module.  Dialog 
design  rules  and  guidelines  for  evaluation  and  usability  of  user  interfaces,  discussed  in 
Chapter  III,  have  been  applied  to  the  overall  design  and  implementation  of  the  user 
interface  for  both  the  Interface  Editor  and  Form  Use  application  program. 
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a.  Menu  Commands 


The  Interface  Editor  contains  three  separate  menus  in  its  menu  bar  FILE, 
WINDOW  and  FORMS.  Figure  2  shows  the  menu  bar. 


FILE  WINDOW  FORMS 

Figure  2:  The  Menu  Bar 

The  FILE  menu  is  a  default  menu  item  created  by  the  Prograph  Application 
Editor.  It  contains  only  one  command:  QUIT,  which  closes  all  active  windows  and 
terminates  program  execution.The  Interface  Editor  module  is  activated  by  selecting  the 
INTERFACE  EDITOR  command  from  the  WINDOW  menu.  The  FORMS  menu  enables 
a  user  to  perform  certain  basic  Form  management  operations.  The  FORMS  menu  includes 
the  following  commands: 

1.  New.  This  command  opens  a  window  titled  Design  Form  which  allows  the  user  to 
create  a  new,  untitled  Form.  The  new  Form  is  given  a  name  the  first  time  it  is  saved. 

2.  Open.  This  command  displays  a  standard  Macintosh  Open  dialog  containing  a 
scrolling  list  of  files.  Clicking  the  OPEN  button  or  double-clicking  on  a  File  name 
from  the  scroll  list  will  open  the  selected  (highlighted)  Form  in  the  Interface  Editor’s 
Form  View  Window. 

3.  Close.  This  command  closes  the  active  Form.  If  the  Form  has  been  modified  since  the 
last  time  it  was  saved,  a  dialog  is  displayed  which  allows  the  user  to  save  the  Form,  or 
dismiss  the  dialog  and  close  the  current  form  without  saving  it. 

4.  Save.  This  command  saves  the  active  Form  to  a  disk  file.  If  a  file  already  exists  with 
the  same  name  as  the  active  Form,  the  file  is  overwritten. 

5.  Save  As.  This  command  opens  a  standard  Macintosh  Save  dialog  which  allows  the 
user  to  specify  a  new  name  for  the  active  Form.  If  the  Form  is  saved  under  a  new 
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name,  the  active  Form  is  renamed,  saved  to  disk  (with  the  new  name),  and  the  old  file 
is  closed  (retaining  its  old  file  name  and  Form  definition). 

6.  Page  Setup.  This  command  allows  the  user  to  specify  printing  parameters  such  as 
paper  size  and  orientation. 

7.  Print.  This  command  prints  the  active  window. 

b.  The  Icon  Bar 

The  icon  bar  consists  of  ten  icon  buttons  which  allow  the  user  to  access 
Interface  Editor  commands  independent  of  the  FORMS  pull-down  menu.  In  addition  to  the 
commands  found  in  the  FORMS  menu,  a  number  of  other  commands  are  included  in  the 
icon  bar.  Figure  3  shows  the  icon  bar. 


■ 

h' 

m t 

■ _ 

W|I 

310 

Figure  3:  The  Interface  Editor  Icon  Bar 


Icon  buttons  descriptions  (from  left  to  right,  top  to  bottom)  are: 

1.  New.  This  command  is  the  same  as  described  in  the  FORMS  menu. 

2.  Open.  This  command  is  the  same  as  described  in  the  FORMS  menu. 

3.  Edit  This  command  is  the  same  as  described  in  the  FORMS  menu. 

4.  Save.  This  command  is  the  same  as  described  in  the  FORMS  menu. 

5.  Save  As.  This  command  is  the  same  as  described  in  the  FORMS  menu. 

6.  Print  This  command  is  the  same  as  described  in  the  FORMS  menu. 

7.  Delete.  This  command  allows  the  user  to  delete  the  active  Form  from  disk.  The  Delete 
command  can  not  be  undone.  A  dialog  prompt  is  displayed  giving  the  user  the 
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opportunity  to  cancel  the  command  or  confirm  the  selection  before  a  Form  is 
permanently  deleted. 

8.  Preferences.  This  command  allows  the  user  to  select  background  and  foreground 
colors  for  displaying  a  Form  in  the  Interface  Editor.  These  preferences  do  not  become 
part  of  the  Form’s  definition,  and  are  used  only  by  the  Interface  Editor. 

9.  Help.  This  command  opens  a  user  help  window. 

6.  Windows 

The  Interface  Editor  window  is  the  main  window  for  the  Interface  Editor  module, 
and  is  shown  in  Figure  4.  In  addition  to  the  icon  bar  described  earlier,  the  following  items 
appear  in  the  window: 
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1.  Current  Form  Title.  This  command  displays  the  name  of  the  active  Form. 

2.  Data  and  Time.  The  current  date  and  time  are  displayed  at  the  top  right  of  the  window, 
just  below  the  icon  bar.  The  date  and  time  are  controlled  by  the  Interface  Editor 
Window’s  Idle  Method  which  is  defined  in  the  Application  Builder’s  Window  editor. 

3.  Active  DB.  This  box  displays  the  name  of  the  database  which  the  Form  is  being 
designed  for. 

4.  Form  View  Window.  This  window  occupies  about  two-thirds  of  the  Interface  Editor 
window  area,  and  is  actually  a  Macintosh  canvas  object  which  supports  Quickdraw2 
editing  and  graphics.  When  the  Interface  Editor  module  is  first  activated,  the  form 
view  window  appears  black  in  color,  signifying  an  empty  form  view  window  (i.e.,  no 
active  or  open  Form).  Additionally,  the  Form  name  display  reads  “<no  currently 
active  form>.  When  a  Form  is  opened,  the  form  view  window  background  changes  to 
the  user-defined  background  color,  and  rectangles  representing  fields  of  the  current 
Form  appear,  along  with  corresponding  labels.  When  the  active  Form  is  closed  or 
deleted,  the  form  view  window  once  again  becomes  black  in  color.  Each  field  of  a 
Form  is  a  descendent  of  the  Prograph  Window  Item  class.  In  order  for  objects  of  this 
class  to  be  visible  in  a  window,  they  must  first  be  included  in  the  window’s  item  list 
(a  list  of  all  window  items  belonging  to  the  window).  Displaying  a  Form  in  the  form 
view  window  is  a  two-step  process.  The  location  of  each  Form  field  is  determined 
relative  to  the  window,  and  appropriate  field  attributes  are  set  to  reflect  this  data.  Once 
field  locations  have  been  determined,  each  field  object  is  added  to  the  item  list  of  the 
Interface  Editor  window  (the  owning  window  of  the  canvas  object).  This  is  not 
sufficient,  however,  to  permit  graphical  manipulation  of  field  objects.  Graphical 
operations  such  as  dragging  and  resizing  of  objects  is  accomplished  in  a  canvas 
object.  Since  a  canvas  object  is  itself  a  descendent  of  Window  Item,  it  can  not  contain 
other  Window  Item  objects.  The  solution  to  this  problem  is  to  place  a  canvas  (the  form 

2.  Quickdraw  is  the  part  of  the  Macintosh  Toolbox  that  supports  creation  of  complex  graphic  oper¬ 
ations  [Apple85  p.  1-137]. 
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view  window)  on  top  of  the  Interface  Editor  window.  Canvas  objects  (in  this  case, 
rectangles)  are  then  added  to  the  canvas  directly  on  top  of  each  field  object.  Thus,  a 
Form  is  displayed  as  a  2-layer  screen  display.  The  bottom  layer  contains  the  actual 
field  object  and  the  top  layer  contains  the  rectangle  which  bounds  the  field  objects. 
Whenever  a  field  is  moved  or  resized,  only  the  canvas  object  is  actually  manipulated 
directly.  The  corresponding  field  object  (in  the  window  item  list),  is  updated  using 
positional  information  obtained  from  its  corresponding  canvas  rectangle  object.  This 
layering  process  is  not  required  when  Forms  are  displayed  in  Input  and  Display  Form 
windows  by  the  Query  Editor,  since  graphical  operations  on  fields  are  not  permitted 
in  these  windows. 

5.  Quit  Button.  Selecting  this  button  quits  the  Interface  Editor  module. 

6.  Close  Box.  A  close  box  is  located  in  the  upper  left-hand  comer  of  the  window. 
Clicking  in  this  box  is  equivalent  to  selecting  the  Close  command  in  the  FORMS 
menu  or  clicking  the  QUIT  button. 

a.  The  Design  Form  Window 

The  Design  Form  window  is  activated  when  a  user  selects  the  New  menu 
item,  types  a  command-N  sequence  from  the  keyboard,  or  selects  the  New  Form  icon  from 
the  icon  bar.  Figure  5  shows  the  Design  Form  window.  This  window  allows  a  user  to  create 
a  new  form  object,  and  consists  of  the  following  objects: 
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Figure  5:  The  Design  Form  Window 

1.  Field  Names.  This  is  a  scroll  list  which  contains  the  names  of  the  fields  defined  for 
the  form  being  designed. 

2.  Name.  This  is  an  edit  text  object  which  is  located  directly  below  the  Field  Names  scroll 
list  and  allows  a  user  to  enter  field  names  from  the  keyboard.  If  a  field  name  is  too 
long  to  fit  into  the  viewable  portion  of  the  edit  text  object,  the  text  automatically 
scrolls  to  the  right  as  the  user  types.  Each  field  name  must  be  unique. 

3.  Field  Type.  This  is  a  radio  set  object  which  allows  a  user  to  select  the  object  type  of 
the  field.  The  values  of  the  radio  set  are  static,  independent  on  any  database  definition 
and  can  not  be  changed  by  the  user. 
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4.  Relations.  This  is  a  pop-up  menu  object  which  contains  the  names  of  the  relations  of 
the  database  which  the  Form  is  being  designed  for. 

5.  Attributes.  This  is  a  pop-up  menu  object  which  contains  the  names  of  the  attributes 
associated  with  the  relation  which  is  currently  visible  in  the  relations  pop-up  menu. 

6.  Data  Type.  This  is  a  pop-up  menu  object  which  contains  the  name  of  the  data  type 
associated  with  the  attribute  which  is  currently  visible  in  the  attributes  pop-up  menu. 

7.  Font.  This  is  a  pop-up  menu  object  which  contains  font  names.  The  font  name  effects 
the  appearance  of  data  entered  into  the  associated  Form  field. 

8.  Font  Size.  This  is  a  pop-up  menu  object  which  contains  font  sizes.  The  font  size  effects 
the  appearance  of  data  entered  into  the  associated  Form  field. 

9.  Add  New  Field  Button.  Selecting  this  button  activates  the  Name  field  to  accept  text 
from  the  keyboard. 

10.  Enter  Data  Button.  Selecting  this  button  enters  the  description  of  the  field  whose 
name  is  currently  highlighted  in  the  Field  Names  scroll  list.  A  field’s  description  is 
defined  by  the  text  which  appears  in  the  Name  field,  the  values  which  appear  in  the 
windows  pop-up  menus,  and  the  selected  value  of  the  Field  Type  radio  button  set. 

1 1.  Delete  Field  Button.  Selecting  this  button  deletes  the  field  whose  name  is  currently 
highlighted  in  the  Field  Names  scroll  list  from  the  Form. 

12.  Tab  Order  Button.  Selecting  this  button  activates  a  separate  modal  window  (the  Tab 
Order  Window)  which  allows  the  user  to  define  the  order  in  which  fields  are  accessed 
when  the  Tab  key  is  selected. 

13.  Cancel  Button.  Selecting  this  button  cancels  all  changes  made  to  the  Form  and 
closes  the  Design  Form  window  without  saving  the  Form. 

14.  Done  Button.  Selecting  this  button  activates  a  dialog  box  which  prompts  the  user  to 
name  the  Form  which  is  being  designed.  The  user  has  the  option  of  naming  and  saving 
the  Form,  cancelling  the  dialog  and  returning  to  the  Design  Form  window,  or  closing 
the  Design  Form  window  without  saving  the  Form. 
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15.  Help  Button.  Selecting  this  button  activates  a  help  window  associated  with  the 
Design  Form  window. 

b.  Edit  Form  Window 

The  Edit  Form  window  is  similar  in  appearance  and  function  to  the  Design 
Form  window  with  transparent  differences  in  the  underlying  implementation  of  the 
controlling  methods  and  the  window  title  which  appears  at  the  top  of  the  window.  The  Edit 
Form  window  can  only  be  accessed  if  a  Form  is  currently  active  in  the  Form  View  window, 
and  allows  editing  of  the  active  Form  object  When  the  window  is  opened,  it  contains  a  list 
of  the  active  Form’s  fields  (in  the  currently  defined  tab  order).  Selecting  a  field  name  in  the 
Field  Names  scroll  list  causes  the  values  of  the  field  ( Name ,  Field  Type,  Relations, 
Attributes,  Data  Type,  Font  and  Font  Size)  to  be  displayed  in  their  respective  edit  text  box, 
radio  set  and  pop-up  menus.  Edit  Form  control  buttons  are  identical  to  those  described  for 
the  Design  Form  window.  Figure  6  shows  the  Edit  Form  window. 
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c.  Tab  Order  Window 

The  Tab  Order  window  displays  the  names  of  the  fields  of  a  Form  in  the 
currently  defined  tab  order.  The  purpose  of  the  window  is  to  allow  the  user  to  modify  the 
tab  order  of  a  Form.  Figure  7  shows  the  Tab  Order  window.  The  window  contains  the 
following  objects: 
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Tab  Order 


Field  Names 


Figure  7:  The  Tab  Order  Window 


1.  Field  Names.  This  is  a  scroll  list  identical  to  the  Field  Names  scroll  list  contained  in 
both  the  Design  Form  and  Edit  Form  windows.  Selecting  a  name  in  this  list  causes  the 
field  associated  with  the  name  to  be  the  object  of  the  window’s  manipulation  buttons. 

2.  First  Button.  Selecting  this  button  causes  the  field  which  is  highlighted  in  the  Field 
Names  scroll  list  to  be  moved  to  the  top  of  the  scroll  list  (i.e.,  it  becomes  the  first  field 
in  the  tab  order  defined  for  the  Form). 

3.  Last  Button.  Selecting  this  button  causes  the  field  which  is  highlighted  in  the  Field 
Names  scroll  list  to  be  moved  to  the  bottom  of  the  scroll  list  (i.e.,  it  becomes  the  last 
field  in  the  tab  order  defined  for  the  Form). 

4.  Move  Up  Button.  Selecting  this  button  causes  the  field  which  is  highlighted  in  the 
Field  Names  scroll  list  to  be  moved  up  one  position  in  the  scroll  list. 

5.  Move  Down  Button.  Selecting  this  button  causes  the  field  which  is  highlighted  in  the 
Field  Names  scroll  list  to  be  moved  down  one  position  in  the  scroll  list. 


43 


6.  Cancel  Button.  Selecting  this  button  cancels  all  tab  order  changes  made  to  the  Form 
and  closes  the  Tab  Order  window. 

7.  Done  Button.  Selecting  this  button  closes  the  Tab  Order  window  and  displays  the 
field  names  in  the  new  tab  order  within  the  Design  Form  or  Edit  Form  window 
(depending  on  the  window  which  was  active  when  the  Tab  Order  window  was 
opened).  The  new  tab  order  will  not  actually  be  saved  until  the  Form  is  subsequently 
saved. 

d.  The  Help  Window 

Help  windows  provide  on-line  user  help  relating  to  the  currently  active 
window.  Help  topics  are  selected  from  the  list  of  Help  Topics  by  double-clicking  on  a  topic 
title.  Text  for  the  selected  topic  appears  in  a  scroll  window.  The  Help  window  is  dismissed 
by  selecting  the  Done  button.  Figure  8  shows  the  Help  window  for  the  Interface  Editor  main 
module  window. 
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Select  a  help  topic  by  clicking  on  a  subject 
heading  in  the  "Help  Topics"  list  to  the  right. 
Text  for  the  chosen  topic  will  appear  in  this 
window.  Dismiss  the  help  window  by 
selecting  the  DONE  button. 
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Figure  8:  The  Help  Window 


e.  Field  Information  Window 


The  Field  Information  window  :  •  activated  by  double-clicking  on  a  field  of 
the  active  Form  (the  Form  currently  displayed  in  the  Form  View  window),  and  displays 
information  about  the  selected  field.  The  window  is  dismissed  by  selecting  the  OK  button. 
Figure  9  shows  the  Field  Information  window. 
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Figure  9:  The  Field  Information  Window 
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D.  THE  FORM  USE  APPLICATION 


The  Form  Use  application  program  simulates  the  user  interface  of  the  Query  Editor 
module  and  the  module’s  interaction  with  a  disk-resident  Form.  Objects  defined  for  this 
application  will  form  the  basis  of  the  Query  Editor’s  Form  display,  data  entry  and  data 
validation  (type  checking)  functions. 

1.  Program  Control  Decisions 

Since  this  application  will  ultimately  be  incorpor.*."d  into  the  Query  Editor 
module,  menu  bar  commands  have  been  kept  to  a  minimum.  The  Input  Form  and  Display 
Form  menus  allow  a  user  to  open  either  data  entry  or  data  display  windows.  Additionally, 
users  must  retrieve  Form  objects  from  disk  through  the  standard  Macintosh  Open  dialog. 
Window  activation  and  Form  retrieval  will  become  transparent  to  system  users  once  the 
Form  Use  functions  have  been  integrated  into  the  Query  Editor. 

In  order  to  provide  consistency  for  Form  creation,  editing  and  use,  icon  buttons 
were  included  in  the  Input  Form  and  Display  Form  windows  to  control  data  entry  and 
display  functions. 

2.  Class  Descriptions 

This  section  describes  classes  unique  to  the  Form  Use  application.  Prograph 
System  Classes  will  not  be  discussed.  Figure  10  shows  the  application’s  class  hierarchy. 

a.  Form  Window 

This  class  defines  the  basic  window  in  which  Forms  are  displayed. 

b.  Input  Form  Window 

This  window  inherits  the  basic  window  properties  from  the  Form  Window 
class,  and  adds  control  objects  and  methods  for  inputting  data  into  a  Form. 
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c.  Display  Form  Window 

This  window  inherits  the  basic  window  properties  from  the  Form  Window 
class,  and  adds  control  objects  and  methods  for  displaying  data  from  a  DFQL  query  in  a 
Form. 

d.  Form 

This  class  has  been  imported  directly  from  the  Interface  Editor  module,  and 
contains  the  definition  for  a  Form  object. 

e.  IE  Edit  Text 

This  class  has  been  imported  directly  from  the  Interface  Editor  module,  and 
contains  the  definition  for  IE  edit  text  objects.  Methods  have  been  added  lyhich  support 
data  input  and  display  via  IE  edit  text  objects. 
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3.  User  Interface 

The  menu  bar  contains  two  items:  FILE  and  FORM.  The  FILE  menu  contains 
only  one  item:  QUIT.  This  is  a  standard  default  Prograph  menu  item,  and  allows  the 
application  user  to  terminate  program  execution.  The  FORM  menu  contains  two  items: 
INPUT  FORM  and  OUTPUT  FORM.  The  INPUT  FORM  command  displays  a  Form 
(specified  by  the  user)  in  an  Input  Form  window.  The  OUTPUT  FORM  command  displays 
a  Form  (specified  by  the  user)  in  a  Display  Form  window. 

The  Form  Use  user  interface  is  limited  to  a  set  of  icon  control  buttons  in  the  Input 
Form  and  Display  Form  windows. 

4.  Windows 

a.  Input  Form  Window 

Figure  1 1  shows  the  Input  Form  window.  Forms  created  by  the  Interface 
Editor  module  are  displayed  in  this  window  for  data  entry  purposes.  The  window  contains 
the  following  control  buttons: 

1.  Clear  All.  This  button  clears  all  data  entered  into  the  displayed  Form. 

2.  Clear  Form.  This  button  clears  all  data  currently  visible  in  the  displayed  Form. 

3.  Enter  Data.  This  button  adds  the  data  currently  visible  in  the  displayed  Form  into  the 
attribute  result  of  class  Form  Window. 

4.  Done.  This  button  is  essentially  the  same  as  the  Enter  Data  button,  except  that  the  Input 
Form  window  is  closed  after  the  displayed  data  has  been  added  to  the  list. 

5.  Cancel,  this  button  cancels  the  data  entry  process,  deletes  all  data  currently  contained 
in  the  attribute  result  of  class  Form  Window  and  closes  the  Input  Form  window. 


48 


Figure  11:  Input  Form  Window 


b.  Display  Form  Window 

Figure  12  shows  the  Display  Form  Window.  Forms  created  by  the  Interface 
Editor  module  are  displayed  in  this  window  for  data  display  purposes.  The  window 
contains  the  following  control  buttons  (from  left  to  right): 

1.  First.  This  button  displays  the  first  element  of  a  data  list. 

2.  Last.  This  button  displays  the  last  element  of  a  data  list. 

3.  Previous.  This  button  displays  the  previous  element  of  a  data  list. 

4.  Next.  This  button  displays  the  next  element  of  a  data  list 

5.  Done.  This  button  closes  the  Display  Form  window. 
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Figure  12:  Display  Form  Window 


E.  THE  FORM  OBJECT 
1.  Form  Object 

A  Form  is  an  object  composed  of  one  or  more  fields,  and  defines  a  template  for 
entering  and  displaying  data  in  response  to  DFQL  queries  specified  in  the  Amadeus  Query 
Editor  module.  The  Interface  Editor  module  provides  a  means  of  defining,  modifying  and 
saving  Form  objects 

A  Form  object  consists  of  the  following  attributes: 
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1.  name.  The  Form’s  name  is  assigned  by  the  user  in  the  Interface  Editor  module.  The 
name  attribute  is  used  as  an  input  to  a  DFQL  query,  and  identifies  which  Form  is  to 
be  opened  in  response  to  the  query. 

2.  fields.  This  is  a  list  of  field  objects  associated  with  the  Form. 

3.  end  user.  Identifies  the  owner  of  the  Form  (i.e.,  the  name  or  identifier  of  the  user  or 
class  of  user  who  created  the  Form). 

4.  protected?  This  attributed  identifies  whether  the  Form  is  protected  (e.g.,  read-only, 
read-write,  etc.).  User  access  and  security  issues  are  being  addressed  separately,  and 
are  beyond  the  scope  of  this  thesis. 

2.  Field  Object 

Each  Form  field  is  a  Prograph  Window  Item  object  (a  descendent  of  the  Window 
Item  class).  Fields  supported  by  the  Interface  Editor  are  considered  display  fields 
[Gibson90],  and  consist  of  an  editable  area  on  the  screen  used  for  editing,  displaying,  or 
updating  a  database.  Currently,  the  Interface  Editor  creates  fields  consisting  of  descendents 
of  the  Edit  Text  Window  Item  class  (called  IE  edit  text).  Extending  the  module  to  allow 
additional  types  of  fields  requires  defining  new  subclasses  within  the  Interface  Editor  class 
hierarchy  (subclasses  of  Window  Item)  for  each  new  field  type.  Each  field  object  consists 
of  the  following  attributes: 

1.  name.  This  value  identifies  the  field  with  a  unique  character  string.  The  field  name  is 
assigned  by  the  user  in  the  Interface  Editor  module  at  the  time  the  field  is  defined. 

2.  relation.  This  value  identifies  the  database  relation  which  the  field  is  associated  with. 
This  value  is  assigned  by  the  user  in  the  Interface  Editor  module  at  the  time  the  field 
is  defined. 

3.  attribute.  This  value  identifies  the  database  attribute  which  the  field  is  associated 
with.  This  value  is  assigned  by  the  user  in  the  Interface  Editor  module  at  the  time  the 
field  is  defined. 


51 


4.  font  This  value  identifies  the  font  name  of  the  field.  Data  displayed  in  the  field  will 
appear  in  this  font 

5.  font  size.  This  value  identifies  the  font  size  of  the  field.  Data  displayed  in  the  field  will 
appear  in  this  font  size. 

6.  position.  This  value  identifies  the  position  of  the  field  in  a  Form  object  relative  to  the 
coordinate  system  of  the  window  in  which  it  is  displayed. 

3.  Windows 

Forms  are  displayed  in  either  the  Form  View  window  of  the  Interface  Editor 
module  or  the  Input  Form  window  or  Display  Form  window  of  the  Form  Use  application 
program.  Each  window  is  a  descendent  of  the  Prograph  system  class  Window,  and  inherits 
the  attributes  and  methods  of  its  parent  classes. 

4.  User  Interaction 

User  interaction  with  Forms  is  limited  to  keyboard  and  mouse  input/selection.  For 
data  entry,  an  insertion  cursor  identifies  the  active  field.  The  cursor  is  moved  from  one  field 
to  another  either  by  selecting  the  destination  field  with  a  mouse,  or  by  repeatedly  pressing 
the  tab  key.  The  order  in  which  the  insertion  cursor  moves  from  field  to  field  is  determined 
by  the  tab  order  of  a  Form.  The  tab  order  is  defined  in  the  Interface  Editor  module  at  the 
time  a  Form  is  created. 

5.  Form  Methods 

Methods  for  defining  and  editing  Form  objects  are  contained  in  the  Interface 
Editor  module.  Methods  for  data  manipulation  (entering  and  displaying  data  in  a  Form)  are 
contained  in  the  Form  Use  application. 

6.  Data  Validation 

Data  validation  (type  checking)  is  performed  by  methods  defined  in  the  Form  Use 
application  program.  These  methods  will  ultimately  be  incorporated  into  the  Query  Editor 
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by  using  Prograph’s  selective  load  feature,  which  allows  loading  individual  classes  from 
one  application  into  another. 

Type  checking  is  possible  since  each  Form  is  associated  with  a  specific  database 
and  database  relation.  Each  field  of  a  Form  is  further  associated  with  a  specific  relation 
attribute  (and  corresponding  attribute  data  type).  This  knowledge  is  obtained  from  a 
database  definition  file  which  resides  on  disk  and  is  available  to  the  Interface  Editor  during 
Form  definition.  Type  checking  takes  place  as  data  is  entered  into  a  Form  by  a  method  that 
compares  the  type  of  the  inputted  data  against  the  data  type  of  the  field’s  associated 
relation.  Data  validation  methods  have  not  yet  been  fully  implemented. 

7.  Input  Form 

Forms  used  for  entering  data  are  displayed  in  a  separate  Input  Form  Window  (a 
descendent  of  the  class  Form  Window).  The  window  is  activated  in  conjunction  with  a 
DFQL  query.  Control  objects  (icon  buttons)  are  included  in  the  window. 

8.  Display  Form 

Forms  used  for  displaying  the  results  of  database  queries  are  displayed  in  a 
separate  Display  Form  window  (a  descendent  of  the  class  Form  Window).  The  window  is 
activated  in  conjunction  with  a  DFQL  query.  Control  objects  (icon  buttons)  are  included  in 
the  window. 

9.  Form  Creation  and  Editing 

Forms  are  created  and  edited  in  the  Interface  Editor  module’s  Design  Form  and 
Edit  Form  windows,  respectively. 

10.  Form  Use 

Forms  are  used  by  the  Amadeus  Query  Editor  module  as  part  of  DFQL  queries. 
Although  Forms  can  be  used  for  both  input  and  data  display,  there  is  only  one  Form  class. 
Depending  on  the  intended  use,  the  Form  is  opened  in  either  an  Input  Form  or  a  Display 
Form  window. 
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a.  Input  Forms 

Figure  13  shows  a  DFQL  operation  which  opens  an  Input  Form  (specified  by 
Form  name)  and  inserts  data  entered  via  the  Form  into  a  relation  specified  by  relation 
name. 


Forms  permit  a  user  to  enter  data  one  tuple  at  a  time.  As  data  is  entered,  it  is 
maintained  in  an  attribute  called  result  of  class  Form  Window  as  a  list  of  tuples.  Each  tuple 
represents  the  set  of  data  entered  into  the  fields  of  a  Form.  This  relationship  is  shown  in 
Figure  14. 


result:  list  of  tuples 
( (tuple  1)  (tuple  2) ...  (tuple  n)  ) 

tuole:  list  of  data  retrieved  from  fields 
of  a  displayed  Form 

( data  j,  data2,  data^  data,},  datag  ) 
data:  data  entered  via  the  keyboard 


<• 


Figure  14:  Representation  of  Data  Entered  via  an  Input  Form  Window 
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The  ordering  of  elements  (i.e.,  individual  pieces  of  data)  in  a  tuple 
corresponds  to  the  order  of  attributes  in  a  relation’s  definition.  The  first  element 
corresponds  to  the  first  attribute,  the  second  element  to  the  second  attribute,  and  so  on. 
When  a  Form  object  is  created,  each  of  its  component  fields  is  associated  with  a  specific 
attribute  name.  Since  the  position  of  each  element  of  a  tuple  corresponds  to  a  specific 
attribute  position,  and  each  field  of  a  Form  corresponds  to  a  specific  attribute  name,  this 
information  can  be  used  to  determine  the  proper  position  of  inputted  data  in  a  tuple. 

These  same  relationships  are  used  to  support  type  checking  of  inputted  data. 
Since  each  attribute  has  an  associated  data  type,  this  value  can  be  compared  with  the  type 
of  the  data  entered  into  a  Form  field.  If  a  type  mis-match  is  identified,  the  user  must  correct 
the  data  before  it  can  added  to  a  tuple.  Figure  15  shows  the  field-to-element  mapping.  The 
notation:  fields  etc.  in  Figure  15  refers  to  the  tab  order  of  a  particular  field 

(e.g.,  fieldj  is  the  first  field  in  the  Form’s  tab  order,  field2  is  the  second,  etc.). 
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Given  the  following  definitions; 
relation  (A),  A  j,  A3,  A 4) 

Form:  Add  „  field*  field  3,  field  4 

tuple:  (element],  dement,,  dement},  element^) 


assume  the  following 
field  -  Attribute  mapping: 

by  definition,  the  Attribute-element 
mapping  is: 

field2  A} 

field}  A3 

Then  data  elements  will  be  retrieved  from  Form  fidds  and  stored  in  tuples  as: 
(field  lf  field  3,  fidd2,  fidd4) 

Tuples,  in  turn,  will  be  stored  in  result  as: 

(  (fidd,,  fiddj,  field*  fie  Id  4)  (field,,  fidd*  field*  fidd^™) 


Figure  15:  Example  of  Fidd>to>Element  Mapping 


As  an  example,  assume  that  the  Form  specified  by  Form  name  (see  Figure  13) 
contains  the  following  fields:  Name,  Address,  Age,  Birthdate  and  Phone.  When  the  query 
shown  in  Figure  13  is  processed,  an  Input  Form  window  is  opened,  and  Form  name 
displayed  as  depicted  in  Figure  16. 

If  relation  name  has  been  defined  in  the  database  as: 


relation  name  (Name,  Age,  Address,  Birthdate,  Phone) 


where  Name,  Age,  Address,  Birthdate  and  Phone  are  the  attributes  of  relation  name,  then 
data  entered  into  Form  name  will  be  stored  in  result  as: 
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( (Name  vaiuej,  Age  value  j,  Address  valuej,  Birthdate  value  j,  Phone  value  j) 
(Name  value2,  Age  value2,  Address  value2,  Birthdate  value2,  Phone  valued 

(Name  valuen,  Age  valuen,  Address  value,,,  Birthdate  valuen,  Phone  value,,) ) 


When  the  user  closes  the  Input  Form  window,  the  data  contained  in  result 
becomes  available  to  the  Query  Editor  module. 
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b.  Display  Forms 

Displaying  data  from  a  DFQL  query  follows  a  similar  logic  to  that  described 
above  for  Input  Form.  Figure  17  shows  a  portion  of  a  DFQL  query  that  might  be  used  to 
display  query  results  in  a  Display  Form  window: 


In  this  example,  list  of  tuples  consists  of  a  list  of  list  of  strings,  and  can  be  expressed  as: 


Since 


and 


then 


where 


( (tuple)  (tuple)  (tuple) ...  (tuple)  )3 
tuple  —  >  (element  j,  element 2,  element}, ...  element n) 

element  — >  string 

list  of  tuples  — >  ( (list  of  strings)  (list  of  strings) ...  (list  of  strings) ) 
(list  of  strings)  —  >  (string  j,  string},  string},  ... ,  stringj 


3.  The  notation  ( )  indicates  a  list  Thus  a  list  of  lists  is  represented  as(()()...(>) 


Each  tuple  represents  a  set  of  data  generated  as  a  result  of  a  DFQL  query.  A 
DFQL  query  can  produce  zero,  one  or  many  such  tuples.  The  individual  elements  (in  this 
case,  strings)  of  a  tuple  contain  the  data  which  is  actually  displayed  in  the  Display  Form 
window. 

Just  as  the  field-Attribute  mapping  is  used  to  build  tuples  during  data  entry, 
the  same  relationships  are  used  to  determine  the  proper  field  in  which  to  display  each  tuple 
element.  Using  the  definitions  and  mapping  from  Figure  15,  the  mapping  from  tuple 
element  to  Form  field  can  be  expressed  as: 

ekmentx  - ►  Aj  - ►  field  i 

elementj  - ►  A2  field2 

element}  ►  A3  ^  field 3 

element*  - ►  A4  - ►  field 4 

Tuples  are  displayed  in  a  Display  Form  window  which  contains  the  Form 
specified  by  the  left-hand  input  ( Form  name)  to  the  DFQL  operation  shown  in  Figure  17. 
Data  is  displayed  in  the  Display  Form  window  one  tuple  at  a  time.  Users  can  page  through 
the  data  (list  of  tuples)  using  control  buttons  (First  tuple,  Last  tuple.  Previous  tuple.  Next 
tuple)  defined  in  the  Display  Window  class  (see  Figure  18). 
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Figure  18:  Display  Form  Window 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 


The  purpose  of  this  research  was  to  design  and  implement  an  Interface  Editor  module 
and  a  Form-based  interface  for  the  Amadeus  multi-relational  database  front-end  system. 
The  research  provided  the  initial  stage  of  development  for  a  complete  Form  creation  and 
manipulation  capability  for  Amadeus  users. 


A.  SUMMARY 

An  extensive  literature  review  was  accomplished  in  which  object-oriented 
programming,  the  Prograph  development  environment  and  Human-Computer  Interface 
design  issues  were  researched.  The  design  and  specification  for  a  Form  object,  a  Form 
creation  application  (the  Interface  Editor  module)  and  a  Form-based  user  interface  (the 
Form  Use  application)  were  successfully  implemented.  The  feasibility  of  the  Form  object 
and  application  programs  were  demonstrated  by  simulating  the  Amadeus  Query  Editor 
module’s  use  of  Forms  for  data  entry  and  display. 

B.  CONCLUSIONS 

The  appropriateness  of  the  user  interfaces  developed  for  this  thesis  can  be  most 
effectively  measured  through  formal  testing  by  representative  groups  of  system  end-users. 
Informal  testing  provided  insights  into  the  overall  interface  design,  and  lead  to 
improvements  in  program  control  functions  while  identifying  areas  requiring  further 
development.  The  Interface  Editor,  as  currently  implemented,  is  limited  in  scope  and 
functionality.  It  extends  the  traditional  Macintosh  user  interface  by  incorporation  of  icons 
for  program  control.  However,  the  Form  objects  created  by  the  Interface  Editor  are  limited, 
at  present,  to  only  a  single  field  type.  Additionally,  the  Form  Use  interface  provides  a  single 
record-at-a-time  view  for  data  entry  and  the  display  of  DFQL  query  results.  While 
impacting  overall  system  performance,  these  limitations  are  not  considered  critical.  Rather, 
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they  provide  a  point  of  departure  for  continued  research  into  enhancing  the  user  interface 
for  the  Amadeus  system. 


C  SUGGESTIONS  FOR  FURTHER  RESEARCH 

Further  research  into  the  topics  presented  in  this  thesis  should  include,  but  not  be 
limited  to,  the  following:  expansion  of  the  Interface  Editor  module  to  allow  incorporation 
of  additional  window  item  class  objects  in  a  Form  field;  expansion  of  the  user  help  facility; 
implementation  of  more  extensive  data  validation  beyond  simple  type  checking; 
development  of  a  dynamic  Form  generation  procedure  which  allows  Forms  to  be  generated 
“on-the-fly”  in  response  to  the  output  of  DFQL  queries;  extending  the  Form  object  to  allow 
multiple  record-at-a-time  viewing;  and  revising  the  Interface  Editor  module  to  provide  a 
more  efficient  direct  manipulation  interface. 

1.  Expansion  of  the  Interface  Editor 

The  Interface  Editor  module  should  permit  the  inclusion  of  all  window  items 
supported  by  Prograph  as  field  objects.  This  capability  will  provide  a  more  flexible  Form 
object,  enhancing  the  Query  Editor  module  user  interface  for  both  data  entry  and  display. 
Additionally,  data  representation  will  become  more  responsive  to  user  needs,  since  some 
information  is  more  appropriately  represented  as  a  graphic  object,  such  as  radio  button  sets 
or  check  boxes.  Expanding  the  Interface  Editor  module  to  meet  this  capability  will  require 
defining  new  window  item  subclasses  in  the  same  manner  as  the  IE  edit  text  subclass  of  edit 
text  was  defined.  The  object-oriented  design  of  the  module  is  well  suited  for  this  task. 

2.  Expansion  of  the  User  Help  Facility 

The  Interface  Editor  module  user  help  facility  is  very  basic  in  its  conten;  and 
functionality.  As  currently  implemented,  only  the  Interface  Editor’s  main  module  window 
has  a  fully  functional  help  facility.  Implementation  of  the  help  facility  for  each  module 


62 


window  is  still  required.  Additionally,  it  may  be  desirable  to  develop  a  context-sensitive 

*  .  ' 

help  facility  which  provides  more  responsive  user  help  for  the  system. 

3.  Extension  of  Data  Validation  Procedures 

The  current  data  validation  procedures  employed  by  the  Form  Use  application 
consist  of  simple  type  checking  of  input  data  against  attribute  data  types  defined  for  each 
database.  A  more  robust  data  validation  facility  is  required  which  is  capable  of  supporting 
database  unique  data  types,  including  formatted  data  such  as  date  fields.  Consideration 
should  also  be  given  to  the  inclusion  of  range  checking  (checking  for  out  of  range  values 
vice  simply  verifying  the  correctness  of  the  associated  data  type). 

4.  Dynamic  Form  Generation. 

Currently,  all  Forms  used  by  the  Query  Editor  must  be  defined  prior  to  use, 
requiring  a  priori  knowledge  of  DFQL  queries  and  their  results.  This  is  sufficient  for 
processing  data  using  “canned”  queries.  However,  the  ability  to  dynamically  generate  a 
Form  based  on  DFQL  query  results  will  provide  much  greater  system  flexibility. 

5.  Extension  of  the  Form  Object 

The  current  Form  object  is  only  capable  of  displaying  query  results  one  record  at 
a  time.  This  provides  a  useful,  but  limited  view  for  the  user.  The  Form  object  should  be 
extended  to  permit  simultaneous  display  of  multiple  records  on  a  single  Form. 

6.  Extension  of  the  Interface  Editor  Direct  Manipulation  Interface 

The  Interface  Editor  module  interface  makes  use  direct  manipulation  features  for 
dragging  and  resizing  Form  fields.  However,  Form  creation  and  editing  takes  place  in 
separate  modal  windows.  The  use  of  modal  windows  restricts,  to  a  certain  degree,  the  user’s 
actions.  A  more  effective  interface  might  be  realized  if  all  Form  manipulation  (including 
creation  and  editing)  occurs  in  the  Form  View  window  rather  than  separate  modal 
windows.  This  would,  however,  require  extensive  modifications  to  the  underlying 
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functionality  of  the  interface.  User  testing  may  determine  whether  the  efforts  required  to 
provided  such  a  feature  are  worth  the  cost  associated  with  re-designing  the  interface. 
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APPENDIX  A 


DEVELOPMENT  NOTES 

The  Interface  Editor  Module,  Form  object  and  Form  Use  application  were  developed 
using  Prograph  version  2.5.2  on  a  Macintosh  Ilfx  computer  with  8  MB  of  RAM,  a  210  MB 
hard  disk  and  an  Apple  21”  color  monitor.  The  operating  system  was  System  7.0  (with 
System  7  Tuner  installed).  This  configuration  is  considered  adequate  for  developing 
medium  to  large-sized  Prograph  applications. 

Version  2.5.2  of  Prograph  fixes  a  number  of  “bugs”  present  in  earlier  versions. 
Additionally,  version  2.5.2  replaces  two  Prograph  Extensions  and  two  Window  Class 
methods  found  in  version  2.5. 1.  For  these  reasons,  the  applications  and  classes  developed 
for  this  thesis  may  not  work  properly  on  systems  running  Prograph  versions  2.5  or  2.5.1. 
Version  2.5.2  update  patches  are  available  directly  from  TGS  or  from  commercial 
electronic  bulletin  board  systems  (such  as  America  OnLine  and  CompuServ). 

The  Icon  Button  Class  (a  descendent  of  Click  Item)  was  used  to  implement  the  icon 
buttons  used  in  the  applications  developed  for  this  thesis.  This  class  is  not  part  of  the 
standard  Prograph  system  release,  and  is  available  separately  from  TGS  as  part  of  the 
Prograph  Goodies  Disk.  Icon  bar  icons  were  created  using  ResEdit,  and  are  stored  as  PICT 
resources  in  the  resource  fork  of  the  Interface  Editor  application. 

A  large-screen  color  monitor  (19”  or  larger)  is  recommended  when  developing 
Prograph  applications.  It  is  not  unusual  to  have  a  dozen  or  more  windows  open 
simultaneously,  each  displaying  a  method,  case,  attribute  or  class  window.  The  larger 
screen  size  allows  simultaneous  viewing  of  multiple  windows,  especially  when  debugging 
a  program  using  Prograph’s  single-step  mode  for  animating  data-flow  diagrams. 
Additionally,  Prograph  uses  color  coding  to  distinguish  icon  and  dataflow  states,  which 
complicates  program  development  on  a  black  and  white  or  grey-scale  monitor.  Figure  1 
shows  a  typical  21”  screen  during  program  development. 
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Figure  1.  Multiple  Windows  Open  During  Application  Development 


The  interface  for  the  Interface  Editor  module  was  developed  for  a  13”  (or  larger) 
monitor  (ideally  8-bit  color,  however  the  effect  of  color  icons  will  not  be  degraded  when 
viewed  on  a  grey  scale  monitor).  Although  the  module  will  run  on  a  compact  Macintosh 
computer  (compact-mac)  which  is  capable  of  running  Prograph1,  the  compact-mac’s  9” 
black  and  white  monitor  will  not  correctly  display  icon  buttons  (a  consequence  of 
attempting  to  display  8-bit  graphics  on  a  1-bit  monitor).  Additionally,  the  Interface  Editor 
main  window  exceeds  the  dimensions  of  a  9”  monitor. 

Prograph  is,  essentially,  a  list  processing  language.  Prior  experience  with  list 
processing  is  not  necessary  in  order  to  use  Prograph.  However,  in  order  to  take  full 


1.  Minimum  system  requirements  for  Prograph  are:  Macintosh  Plus  generation  with  128K  ROM  and 
1MB  of  RAM.  Prograph  can  be  run  from  floppy  disks,  however  a  hard  disk  is  recommended. 
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advantage  of  the  language,  familiarity  with  lists  and  list  processing  techniques  is  strongly 
recommended. 

Prograph  implements  most  of  the  Macintosh  Toolbox  calls  described  in  Apple 
Computer  Inc's  Inside  Macintosh  [Apple85]  and  Macintosh  Technical  Notes  (published 
separately  from  Inside  Macintosh ).  However,  Prograph’s  accompanying  Toolbox 
documentation  (Tutorial  and  Reference  Manuals  [TGS90b  and  TGS90c]  and  on-line  help 
facilities)  are  incomplete.  Serious  Prograph  development  efforts  require  access  to  the 
complete  set  of  Inside  Macintosh  and  Technical  Notes ,  the  definitive  reference  sources  for 
Macintosh  program  development. 
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APPENDIX  B 


PROGRAPH  BASICS 

A.  LANGUAGE  BASICS 

1.  Pictorial  Representation  of  the  Language 

Prograph  programs  are  composed  entirely  of  icons  and  amplifying  text  Figure  1 
shows  common  icons  used  in  constructing  Prograph  programs. 


Figure  1.  Examples  of  Prograph  Icons 


2.  Control  Structures 

Prograph  Control  Structures  control  the  flow  of  execution  within  a  program. 
Control  structures  are  composed  of  icons  (either  an  ‘X’  or  a  ‘V’)  that  are  attached  to  the 
right-hand  side  an  operator,  and  are  activated  on  either  the  success  or  failure  of  the 
associated  operation.  The  default  control  structure  is  success.  Operations  fail  in  one  of  three 
ways:  (1)  in  a  match  operation,  the  items  being  compared  do  not  match,  (2)  a  Boolean 
operation  returns  a  FALSE  value,  or  (3)  a  FAIL  condition  is  propagated  to  a  particular 
operation.  Operations  may  also  generate  errors  under  certain  conditions,  including:  type 
mis-matches,  syntax  errors,  or  a  specific  program  condition  which  can  not  be  satisfied  by 
the  particular  control  structure.  Figure  2  shows  typical  Prograph  control  structures.  An  ‘X’ 
within  a  control  structure  indicates  that  it  is  activated  if  the  associated  operation  fails.  A 
check  mark  (V)  indicates  that  the  control  structure  is  activated  if  the  associated  operation 
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within  a  control  structure  indicates  that  it  is  activated  if  the  associated  operation  fails.  A 
check  mark  (V)  indicates  that  the  control  structure  is  activated  if  the  associated  operation 
succeeds.  Other  graphics  inside  the  control  structure  icon  indicate  additional  action  to  be 
taken. 


Figure  2:  Prograph  Control  Structure  Icons 


The  most  basic  Prograph  conditional  execution  format  is  the  Next  Case  with  an 
accompanying  match  operation  or  conditional  test.  Figure  3  depicts  a  conditional  test  with 
a  match  on  success  control  structure  which  tests  for  a  specific  condition  to  determine  which 
of  two  case  windows  will  be  executed. 


Figure  3:  Example  of  the  Next  Case  on  Success  Control  Structure 
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3.  Classes  and  Inheritance 

Classes  of  objects,  and  all  inheritance  relationships,  appear  on  the  screen  as  trees 
of  icons.  The  Prograph  class  system  provides  a  means  for  constructing  a  new  class  from 
an  existing  class  through  inheritance.  A  Prograph  class  can  inherit  from  at  most  one  parent. 
This  is  referred  to  as  single  inheritance. 

The  class  icon  is  a  hexagon  which  is  divided  into  two  parts:  attributes  on  the  left, 
and  methods  on  the  right.  Double-clicking  on  the  left  half  of  a  class  icon  displays  the 
attributes  of  the  class,  while  double-clicking  on  the  right  half  displays  the  class  methods. 
Figure  4  depicts  this  relationship. 


Figure  4:  Prograph  System  Class  Icons  and  Component  Parts  of  “Window  Item  Class’* 
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4.  Attributes 


Prograph  attributes  are  displayed  in  an  Attributes  Window.  There  are  two  types 
of  Prograph  attributes:  instance  and  class.  An  instance  attribute  may  have  a  different  value 
for  each  instance  of  a  class.  Class  attributes,  however,  have  one  value  for  the  class  as  a 
whole.  Therefore,  the  value  of  a  class  attribute  is  shared  by  all  instances  of  the  class.  The 
attribute  icon  is  a  downward  pointing  triangle. 

5.  Methods  and  Cases 

A  Prograph  method  consists  of  a  sequence  of  one  or  more  dataflows,  called  cases. 
A  case  consists  of  an  input  bar,  an  output  bar,  operations  and  datalinks.  Data  flows  into  a  case 
via  the  input  bar,  and  out  through  the  output  bar. 

Methods  are  referenced  in  one  of  four  ways:  universal,  data-determined,  explicit 
and  context-determined  (see  figure  5).  These  terms  correspond  to  the  terms  global,  regular, 
early-bound  and  self,  which  are  more  commonly  used  in  object-oriented  programming 
literature  [Wu91c  p.  71].  Essentially,  the  calling  format  determines  where  Prograph  looks 
for  the  referenced  method  in  the  class  hierarchy. 

(1)  Universal.  This  is  a  call  to  a  global  method. 

(2)  Data-determined.  Prograph  looks  for  the  referenced  method  in  the  class 
of  the  object  which  flows  into  the  leftmost  terminal  of  the  method. 

(3)  Explicit.  Prograph  looks  for  the  referenced  method  in  the  class  which  is 
explicitly  listed  to  the  left  of  the  in  the  method  icon.  If  the  method  is  not  found  in  the 
explicitly  listed  class,  then  Prograph  uses  inheritance  links  to  check  ancestor  classes  for  the 
method. 

(4)  Context-determined.  Prograph  looks  for  the  referenced  method  in  the 
same  class  as  the  current  method  that  contains  the  method  referencing  operation.  This 
allows  a  method  to  send  a  message  to  itself. 
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Figure  5:  Method  Calling  Formats 


6.  Operations 

An  operation  is  the  basic  executable  component  of  a  case.  Operations  have  a 
name,  zero  or  more  inputs,  zero  or  more  outputs  and  a  distinctive  icon.  Data  flows  into  an 
operation  through  terminals  located  on  the  top  of  the  operation  icon,  and  out  through  roots 
located  on  the  bottom  of  the  icon.  Prograph  provides  a  special  icon,  called  z  synchro  link 
which  forces  a  specific  execution  order  on  a  pair  of  operations  (see  figure  6).  However, 
the  synchro  link  does  not  guarantee  that  the  operations  will  execute  consecutively,  only  that 
one  will  execute  before  the  other.  [TGS90c  p.  7]  In  the  example  shown  below,  A  will 
execute  before  B.  However,  there  is  no  guarantee  that  B  will  execute  immediately  after  A, 
since  there  is  no  way  to  determine  when  C  will  execute. 
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7.  Message  Passing 

Message  passing  in  Prograph  is  similar  to  most  other  object-oriented  languages. 
Some  differences  occur,  however,  because  of  the  dataflow  nature  of  the  Prograph  language. 
Essentially,  in  Prograph  objects  flow  into  operations  to  initiate  actions.  In  a  “standard” 
object-oriented  programming  language,  a  stationary  object  sends  a  message  to  another 
stationary  object  Although  the  models  are  somewhat  different,  the  basic  concepts  are  the 
same.  {TGS90b  p.  93] 

8.  Primitives 

Prograph  primitives  are  calls  to  compiled  methods,  and  are  categorized  into 
sixteen  groups,  including:  Application,  Bit,  Data,  File,  Graphics,  Instances,  Interpreter 
Control,  I/O,  Lists,  Logical/Relational,  Math,  Memory,  Strings,  System,  Text  and  Type. 
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Primitives  comprise  the  kernel  of  Prograph’s  functionality.  Unlike  other  object-oriented 
programming  languages.  Prograph  primitives  do  not  belong  to  any  class.  This,  and  the  fact 
that  the  language  supports  regular  data  types  such  as  string,  integer,  Boolean  and  real 
make  Prograph  a  hybrid  object-oriented  programming  language.  [Wu91c  p.  72] 

B.  THE  PROGRAPH  ENVIRONMENT 

The  Prograph  language  is  seamlessly  integrated  with  the  Prograph  development 
environment.  An  editor  provides  a  visual  interface  for  creating  and  modifying  programs, 
while  an  interpreter  contains  features  which  allow  dataflow  diagrams  to  be  displayed 
during  execution,  in  effect  graphically  animating  the  flow  of  data  throughout  a  program  as 
each  operation  is  executed  [TGS90a  p.  21]. 

1.  Editor 

The  Prograph  editor  is  context  sensitive,  so  syntax  errors  are  caught  at  the  time 
they  are  created,  eliminating  the  need  for  a  traditional  debugger.  During  program 
execution,  run-time  errors  are  flagged,  program  execution  is  halted  and  the  appropriate 
dataflow  diagram  displayed.  This  enables  the  user  to  correct  the  error  and  immediately 
resume  execution.  An  on-line  help  system  is  also  available  and  is  fully  integrated  into  the 
editor. 


2.  Interpreter 

The  Prograph  interpreter  is  highly  interactive.  Program  execution  may  be  paused 
at  any  point  and  dataflow  diagrams  and  data  values  examined,  allowing  simultaneous 
execution  and  editing  of  applications.  Additionally,  program  execution  may  be  traced  step 
by  step,  allowing  the  flow  of  data  through  a  program  to  be  traced  visually.  If  a  dataflow 
diagram  is  changed  while  execution  is  paused,  the  interpreter  backs  up  to  the  change  and 
continues  execution  from  that  point. 
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C  COMPILER 


The  Prograph  compiler  generates  stand-alone  application  programs,  and  allows 
linking  to  modules  developed  with  other  programming  languages  such  as  MPW  C  and 
Think  C.  The  compiler  also  includes  an  intelligent  Project  Manager  which  keeps  track  of 
the  files  needed  to  build  a  particular  application.  The  Project  Manager  selects  only  the  code 
actually  required  when  building  a  stand-alone  application  and  informs  the  user  of  any 
missing  code.  If  the  compiler  detects  an  error  in  a  Prograph  file,  the  user  can  enter  the 
editor/interpreter  to  see  the  operation  that  generated  the  error. 

A  certain  amount  of  overhead  is  normally  introduced  when  creating  stand-alone 
applications.  In  Prograph,  stand-alone  applications  which  do  not  use  system  classes  require 
an  additional  SOKbytes  of  overhead,  while  those  with  system  classes  require  an  additional 
130Kbytes.  However,  the  execution  speed  of  compiled  Prograph  code  is,  on  the  average, 
15  times  faster  than  the  same  interpreted  code  [TGS90a  p.  33-36]. 
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APPENDIX  C 


DATABASE  BASICS 


A.  DEFINITIONS 

1.  Database 

In  a  general  sense,  a  database  is  a  collection  of  related,  recordable  facts  that  have 
implicit  meaning.  To  be  more  precise,  however,  a  database  may  be  defined  as  a  “shared 
collection  of  inter-related  data  designed  to  meet  the  varied  information  needs  of  an 
organization”  [Falby91  p.  14].  Databases  have  the  following  properties  [Elmasri89  p.  3-4]: 

1.  Logically  coherent  collection  of  data  with  some  inherent  meaning. 

2.  Designed,  built  and  populated  with  data  for  a  specific  purpose. 

3.  Represents  some  aspect  of  the  real  world  (referred  to  as  the  mini-world). 

2.  Database  Management  System  (DBMS) 

A  DBMS  is  a  general-purpose  software  system  for  defining,  constructing  and 
manipulating  a  database. 

3.  Relational  model 

The  relational  model  for  Database  Management  Systems  was  first  introduced  in 
1970.  The  model  is  founded  solidly  on  mathematical  principles  and  provides  simple, 
uniform  data  structures.  The  relational  model  represents  a  database  as  a  collection  of  tables. 
Each  row  in  a  table  represents  a  collection  of  related  data  values  which  can  be  interpreted 
as  a  fact  describing  an  entity  or  a  relationship  instance.  The  table  name,  and  the  names  of 
the  table  columns,  provide  additional  meaning  to  the  values  in  each  now  of  the  table.  Each 
row  in  a  relational  database  relation  is  called  a  tuple,  and  each  column  title  is  called  an 
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attribute.  The  Table  itself  is  referred  to  as  a  relation.  [Elmasri89  p.  135-137].  Figure  1 
shows  a  relation,  named  EMPLOYEE,  from  a  relational  database. 


EMPLOYEE 


tuples 


Name 

Age 

Sex 

SSN 

Salary 

Jane  Doe 

35 

F 

123-45-6789 

50,000.00 

Bill  Jones 

28 

M 

111-22-3344 

32,000.00 

John  Smith 

30 

M 

000-99-3456 

28,000.00 

Figure  I:  Table  from  a  Relational  Database 


4.  Data  Manipulation  Languages  &  Database  Query  Languages 

Database  Management  Systems  can  provide  two  types  of  Data  Manipulation 
Languages  (DML)  which  allow  users  to  manipulate  data  in  the  database:  high-level  or  non¬ 
procedural  and  low-level  or  procedural.  High-level  DML’s  can  be  used  either  as  stand¬ 
alone  languages  or  can  be  embedded  in  a  general-purpose  programming  language.  When 
used  as  a  stand-along  language,  high-level  DML  statements  are  entered  interactively  from 
a  terminal  by  a  DBMS  user,  and  the  DML  is  called  a  database  query  language.  Low-level 
DML’s  must  always  be  embedded  in  a  general-purpose  programming  language.  Casual 
DBMS  users  normally  use  a  high-level  query  language  to  manipulate  the  database,  while 
programmers  use  a  DML  which  has  been  embedded  in  a  general-purpose  programming 
language. 
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APPENDIX  D 


INTERFACE  DESIGN  GOALS  AND  CONCERNS 

The  goal  of  interface  design  should  be  to  empower  people,  leading  to  an  increase 
in  user  experience,  productivity  and  creativity  [Dertouzos90,  Butler90  p.  349].  Users  are 
empowered  when  they  have  “a  clear  predictive  model  of  system  performance  and  a  sense 
of  mastery,  control,  and  accomplishment”  [Don92  p.  69].  To  truly  empower  a  user, 
however,  the  interface  designer  must  fully  understand  the  difference  between  “efficiency” 
in  terms  of  computer  science  and  “productivity”  in  terms  of  getting  more  value  from  work 
[Winograd90].  A  well  designed  interface  should  be  practically  transparent,  allowing  users 
to  concentrate  directly  on  the  task  at  hand  [Shneiderman92]. 

A.  THE  DESIGN  PROCESS 

The  design  process  should  typically  begin  with  an  understanding  of  the  system’s 
intended  users  to  develop  a  user  profile.  It  is  not  uncommon  to  characterize  system  users 
into  different  groups  or  classes.  This  may  result  in  different  design  goals  for  each  user  class. 
For  example,  classifying  users  as  novice,  intermediate  and  advanced  will  require  unique 
features  for  each  user  class.  [Schneiderman92  pages  145- 148] 

After  completing  the  user  profile,  task  analysis  should  be  conducted  to  identify  the 
functionality  required  of  the  proposed  system.  Good  task  analysis  means  continual  user 
testing,  starting  as  soon  as  the  work  begins.  Key  elements  of  the  design  should  emerge  from 
the  task  analysis,  rather  than  being  shaped  to  fit  the  results  of  the  user  testing  [Norman  in 
Laurel90  page  9], 

Change  is  important  to  good  interface  design.  Procedures  that  allow  incorporation  of 
changes,  up  to  a  point,  are  considered  critical  to  successful  design.  Ideally,  this  should 
include  an  Iterative  design  methodology  involving  user  testing  and  prototyping  tools  tu 
rapidly  produce  non- functional  and  functional  models  of  the  system  to  elicit  user  feedback 


at  key  stages  of  the  design  process  [Mountford90].  Iterative  design  is  a  process  of 
identifying  a  problem  area,  modifying  the  appropriate  portion(s)  of  the  application,  and  re¬ 
testing.  The  iterative  process  continues  until  a  decision  is  made  to  accept  the  prototype. 
Most  problems  will  disappear  by  the  second  or  third  iteration  [Tognizzini92  page  86]. 

The  cost  of  user  testing  has  been  a  topic  of  debate  in  recent  years.  Historically, 
elaborate  test  scenarios,  complete  with  high-tech  equipment  for  recording  and  analyzing 
user  actions  and  perceptions,  reinforced  the  belief  that  user  testing  was  a  costly 
undertaking.  Newer  approaches  described  in  [Tognazzini91  pp.  79-91]  stress  simplicity 
and  common  sense,  promising  to  make  user  testing  more  acceptable  both  in  terms  of  cost 
and  end-user  productivity.  These  approaches  include: 

1.  Develop  test  scenarios  that  incorporate  situations  that  users  may  face,  then  build 
prototypes  that  enable  evaluation  of  the  situations.  Two  types  of  prototypes  can  be 
built:  horizontal  and  vertical.  Horizontal  prototypes  allow  testing  overall  design 
concepts  by  displaying  all  or  most  of  an  application’s  menus,  windows  and  dialogs 
without  going  into  depth  in  any  one  area.  Vertical  prototypes  allow  greater 
examination  of  specific  parts  of  an  application,  and  are  used  when  new  design 
concepts  and/or  technology  are  involved. 

2.  Prototypes  can  and  should  be  created  in  a  matter  of  days,  not  weeks  or  months.  A  wide 
variety  of  prototyping  tools  are  available  which  greatly  aid  prototype  development. 

3.  Choose  test  subjects  carefully.  In  the  initial  stages,  user  testing  should  focus  on 
interface  issues.  Content  testing  (testing  the  actual  performance  and  applicability  of  a 
system  -  such  as  an  accounting  package  or  CAD  package)  is  generally  not  a  concern 
during  iterative  design  testing.  Studies  have  shown  that  a  maximum  of  three  test 
subjects  per  design  iteration  is  sufficieni  [Tognazzini  page  82],  Any  more  than  that 
will  simple  serve  to  confirm  problems  already  identified.  Each  iteration  should 
involve  new  test  subjects  {Tognazzini  page  270].  Once  the  interface  design  has  been 
finalized,  validation  testing  should  be  conducted.  Validation  testing  requires  a 


carefully  chosen  representative  sample  of  the  intended  user  population,  and  may  be 
applied  to  late  alpha  or  early  beta  versions  of  the  application. 

4.  Apply  a  standardized  methodology  for  observing  test  subjects.  Apple  Computer  uses 
a  methodology  called  User  Observation  Through  Thinking  Out  Loud  [Gomoll  in 
Laurel90  pages  85-90].  This  process  does  not  yield  statistical  results.  Rather,  it  allows 
an  observer  to  identify  areas  where  test  subjects  are  having  problems  using  the 
product,  and  provides  information  necessary  to  improve  it. 


B.  FACTORS  THAT  INFLUENCE  INTERFACE  DESIGN 

In  general,  interface  design  problems  can  be  easy  to  describe,  but  extremely  difficult 
to  actually  solve  [Erickson91].  A  good  deal  of  thought,  insight,  ingenuity,  understanding 
of  the  original  problem  and  knowledge  of  the  end-user  are  required;  however  this  still  may 
not  be  enough  to  satisfy  everybody  that  a  solution  is  good. 


1.  Lack  of  Standardized  Methodology 

There  is  no  standard  method  of  looking  at  interface  design.  This  lack  of 
standardization  can  lead  to  confusion  in  design,  testing  and  implementation  of  user 
interfaces.  Russel  summarizes  this  problem  in  [Russel92  p.  71-72]: 

As  the  state  of  graphical  user  interface  design  theory  continues  to  mature  from  its 
beginnings  in  the  mid-eighties,  emphasis  on  reducing  the  burden  of  interface 
programming  has  become  more  prevalent.  Across  the  many  popular  computer 
platforms  used  professionally  today,  a  myriad  of  interface  building  packages  have  been 
designed  with  this  concern  in  mind.  Currently,  however,  no  standard  design 
methodology  exists  and  more  importantly,  no  construction  package  has  emerged  that 
significantly  reduces  programming  effort  while  still  providing  the  application  interface 
programmer  with  full  control  over  the  design  process... . 


2.  Compromise 

Interface  design  is  largely  a  compromise  [Erickson91].  Software  and  hardware 
must  complement  each  other;  an  elegant  software  solution  implemented  on  the  wrong 
platform  will  not  necessarily  function  the  way  the  designers  intended.  Human  factors  must 
also  be  addressed  (i.e.,  the  interface  must  take  into  account  human  capabilities  and 
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limitations).  Sophisticated  features  of  an  interface  may  not  be  practical  if  the  human  user 
cannot  take  advantage  of  them. 

Additionally,  an  interface  design  team  is  usually  inter-disciplinary.  Different 
disciplines  have  different  priorities,  thinking  styles  and  values.  When  people  from  different 
disciplines  get  together,  values  tend  to  collide.  [Kim  in  Laurel90  page  32]  Thus,  competing 
concerns  must  constantly  be  balanced  in  order  to  arrive  at  a  mutually  acceptable  solution. 

3.  Appropriateness  of  the  Interface 

A  common  design  error  is  to  include  too  much  functionality  into  a  system, 
producing  a  number  of  undesirable  side-effects,  including:  excessive  code  to  test,  debug 
and  maintain,  more  complicated  user  manuals  and  help  facilities  and  a  steeper  learning 
curve  and  potentially  higher  cognitive  loading  on  the  user.  Problems  also  arise  if 
insufficient  functionality  is  included.  In  such  cases,  users  may  become  frustrated  because 
of  a  perception  that  the  system  does  not  adequately  support  specific  functions  or  features. 
[Schneiderman92] 

4.  Pressure  to  Produce 

Interface  designers  are  often  under  a  great  deal  of  pressure  to  ship  a  product 
quickly,  resulting  in  a  tendency  to  accept  the  first  promising  design  idea  and  forego  proven 
testing  and  development  procedures  [Mountford90]. 
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APPENDIX  E 


PROGRAM  LISTINGS  FOR: 

THE  INTERFACE  EDITOR  MODULE 

AND 

THE  FORM  USE  APPLICATION 
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